Dynamically generating application-layer traffic optimization protocol maps

ABSTRACT

In general, techniques are described for using routing information obtained by operation of network routing protocols to dynamically generate network and cost maps for an application-layer traffic optimization (ALTO) service. For example, an ALTO server of an autonomous system (AS) receives routing information from routers of the AS by listening for routing protocol updates outputted by the routers and uses the received topology information to dynamically generate a network map of PIDs that reflects a current topology of the AS and/or of the broader network that includes the AS. Additionally, the ALTO server dynamically calculates inter-PID costs using received routing information that reflects current link metrics. The ALTO server then assembles the inter-PID costs into a cost map that the ALTO server may provide, along with the network map, to clients of the ALTO service.

This application is a continuation of U.S. patent application Ser. No.14/252,526, filed Apr. 14, 2014, which is a continuation of U.S. patentapplication Ser. No. 13/110,987, filed May 19, 2011, now U.S. Pat. No.8,700,801, issued Apr. 15, 2014, which claims the benefit of U.S.Provisional Application No. 61/418,793, filed Dec. 1, 2010 and of U.S.Provisional Application No. 61/449,499, filed Mar. 4, 2011, the entirecontent of each of which is incorporated by reference herein.

TECHNICAL FIELD

The invention relates to computer networks and, more specifically, toenhancing content delivery.

BACKGROUND

Peer-to-peer (P2P) and content delivery networks (CDNs) applicationsserve large amounts of data and generate significant amounts of networktraffic. These applications leverage multiple copies of data contentpopulated to multiple different network nodes to allow a requestingagent to obtain portions of the data content from one or more of manypossible data sources. Distributing data content to multiple nodes fordelivery on behalf of applications such as file sharing, real-timecommunication, and on-demand media streaming improves applicationperformance and scalability.

P2P and CDN application clients often select resources naively, that is,without incorporating network topology information or related details.Rather, clients rely on heuristics to approximate such information. As aresult, network data traffic exchanged using these applications maycongest network links, cross service provider network boundariesmultiple times, and generally transit the communication network in amanner that is suboptimal from a user-standpoint and undesirable fromthe point of view of the service provider. For instance, while two peersmay be members of the same service provider network, an overlay linkconnecting the peers may nevertheless traverse multiple networkboundaries, which unnecessarily increases the inter-peer transit coststo the service provider. Furthermore, although distributed applicationscapitalize on excess bandwidth at the data sources to improve throughputand reduce latencies for end-users while also reducing the burden ofcontent providers to provision application servers, the ability tocheaply distribute data content comes at the expense of serviceproviders, which bear the cost of inefficiently transporting networkdata.

A service provider, content provider, or a third party may provide anApplication-Layer Traffic Optimization (ALTO) protocol service toprovide guidance to application clients and content request routersregarding selection of a particular resource from which to obtain datacontent. The ALTO service provides information that incorporatesprovider preferences with regard to network resources to influencenetwork resource consumption patterns while maintaining or improvingapplication performance. In one example, a service provider provisionsan ALTO server for a service provider network with network topology andtopology link cost information. Application clients and content requestrouters send ALTO requests to the ALTO server to obtain a network mapand a corresponding cost map. The network map specifies a set oftopological groupings, or “PIDs,” defined by the ALTO server for thenetwork. A particular PID within a network map may represent a singledevice or device component, a collection of devices such as a networksubnet identified by a network address prefix, a service providernetwork, or some other grouping. A cost map for a corresponding networkmap defines provider preferences respecting inter-PID routing costs forconnections among the various PIDs of the network map. Using the networkmap and cost map provided by the ALTO server, application clients andcontent request routers select serving resources to minimize costs, asspecified by the ALTO maps, between content requesting clients andavailable resources.

As a result, service providers provisioning the ALTO server may directapplication clients and request routers to select resources according toservice provider preferences, which may include optimizing throughputand/or user experience, for instance, reducing costs to the serviceprovider, or promoting other provider objectives. The ALTO service andALTO protocol is described in further detail in J. Seedorf et al., RFC5693, “Application-Layer Traffic Optimization (ALTO) Problem Statement,”Network Working Group, the Internet Engineering Task Force draft,October 2009; and R. Alimi et al., “ALTO Protocol:draft-ietf-alto-protocol-06.txt,” ALTO Working Group, the InternetEngineering Task Force draft, October 2010, each of which isincorporated herein by reference in its entirety.

SUMMARY

In general, techniques are described for using routing informationobtained by operation of network routing protocols to dynamicallygenerate network and cost maps for an application-layer trafficoptimization service, such as that provided by the Application-LayerTraffic Optimization (ALTO) protocol. In one example, an ALTO server ofan autonomous system (AS) receives routing information, such astopology, link state, and link metrics information, from routers of theAS by listening for routing protocol updates output by the routers. Inother words, the ALTO server may execute layer three (L3) routingprotocols so as to snoop or otherwise receive routing protocol updatemessages exchanged between L3 routing devices within the network. Basedon the routing protocol update messages, the ALTO server assemblestopology information representative of the network. Topology informationsnooped by the ALTO server may include information that describes theintra-AS topology of the AS that includes the receiving ALTO server, aswell as information that describes intra-AS topologies of neighboringautonomous systems and of an inter-AS topology of multiple,interconnected autonomous systems. The ALTO server uses the assembledtopology information to dynamically generate an ALTO network map of PIDsthat reflects a current topology of the AS that includes the ALTO serverand/or of the broader network that includes additional ASes. In somecases, the ALTO server functionality may be incorporated within an L3routing device of the network that operates as a peer to other routerswithin the network.

Link metrics (e.g., distance or throughput) received by the ALTO serverin routing protocol updates, autonomous system path lengths, andadministratively configured data determine current inter-PID costs amongthe PIDs of the dynamically generated network map. The ALTO serverdynamically calculates inter-PID costs using received routinginformation that reflects current link metrics. The ALTO server thenassembles the inter-PID costs into an ALTO cost map that the ALTO servermay provide, along with the ALTO network map, to ALTO clients.

Additionally, a master ALTO server may interact with ALTO servers ofother federated autonomous systems to receive network and cost mapsgenerated in the AS-internal ALTO Servers according to their respectivenetwork topology perspectives. Using the detailed topology and costinformation included within such maps for remote areas of the broadernetwork, the master ALTO server generates master network ALTO and costmaps that detail a more complete perspective of available PIDs andinter-PID costs of the broader multi-AS network. The ALTO server maythen pass the master ALTO network and cost maps to ALTO clients and/orto federated ALTO servers to improve inter-AS node selection byapplications.

The described techniques may present one or more advantages. Forexample, dynamically generating and updating ALTO network and costs mapswith an ALTO server using routing information received from networkelements synchronizes the ALTO maps to an ever-changing networkenvironment. As a result, the ALTO network and cost maps provided by theALTO server to ALTO clients may reflect recent updates to the networktopology and/or utilization and may thus improve node selection andincrease application performance. Moreover, automatically creatingnetwork and cost maps may reduce an ALTO server configuration burden onan operator, making an ALTO server implementation viable in alarge-scale service provider environment. Additionally, the techniquesmay use both intra-AS (intra-domain) and inter-AS (inter-domain) routinginformation received from network elements, such as Border GatewayProtocol and Interior Gateway Protocol speakers. An ALTO server thatimplements the techniques may therefore receive and incorporate in ALTOnetwork and costs maps routing information from remote ASes that may notbe administratively configurable within the ALTO server.

In one embodiment, the invention is directed to a method comprisingexecuting a routing protocol on an application-layer trafficoptimization (ALTO) server to receive layer three (L3) network topologyinformation defining routes to endpoints of a network, and aggregating,with the ALTO server, the endpoints into a set of one or more subsets oftopological groupings (PIDs), wherein each PID is associated with adifferent subset of the endpoints. The method further comprisesreceiving, with the routing protocol, a topology informationadvertisement that specifies one or more routes and includes networkaddress information identifying one or more of the endpoints. The methodfurther comprises aggregating, with the ALTO server, the identifiedendpoints into a first one of the set of PIDs. The method also comprisesgenerating, with the ALTO server, an ALTO network map that includes aPID entry to describe each of the PIDs, and sending the ALTO network mapfrom the ALTO server to an ALTO client.

In another embodiment, the invention is directed to a method comprisingexecuting an interior gateway protocol on an application-layer trafficoptimization (ALTO) server, and receiving, with the interior gatewayprotocol, routing information for an autonomous system that includes theALTO server. The method also comprises computing, with the ALTO server,an ALTO cost for a pair of a set of one or more subsets of topologicalgroupings (PIDs) of an ALTO network map based at least on the routinginformation, wherein each one of the set of PIDs is associated with adifferent subset of endpoints of a network that comprises the autonomoussystem. The method further comprises generating an ALTO cost map thatincludes an entry that specifies the ALTO cost between the first memberand second member of the pair of PIDs, and sending the ALTO cost mapfrom the ALTO server to an ALTO client.

In another embodiment, the invention is directed to a method comprisingreceiving a first inter-AS network map and a first inter-AS cost map fora first autonomous system with a master application-layer trafficoptimization (ALTO) server, wherein the first inter-AS network mapcomprises a first set of one or more local and remote subsets oftopological groupings (PIDs), wherein each local and remote PID of thefirst inter-AS network map is associated with a different subset ofendpoints of a network, wherein the local PIDs of the first inter-ASnetwork map specify network address prefixes of the first autonomoussystem and remote PIDs of the first inter-AS network map specify networkaddress prefixes of a second autonomous system, wherein the firstinter-AS cost map specifies ALTO costs for pairs of PIDs of the firstinter-AS network map. The method also comprises receiving a secondinter-AS network map for the second autonomous system with the masterALTO server, wherein the second inter-AS network map comprises a secondset of one or more local and remote PIDs, wherein each local and remotePID of the second inter-AS network map is associated with a differentsubset of the endpoints of the network, wherein the local PIDs of thesecond inter-AS network map specify network address prefixes of thesecond autonomous system and remote PIDs of the second inter-AS networkmap specify network address prefixes of the first autonomous system,wherein the second inter-AS cost map specifies ALTO costs for pairs ofPIDs of the second inter-AS network map. The method further comprisesgenerating, with the master ALTO server, a master ALTO network map forthe network based at least on the first inter-AS network map and thesecond inter-AS network map, and outputting the master ALTO network mapfrom the master ALTO server.

In another embodiment, the invention is directed to an application-layertraffic optimization (ALTO) server comprising a control unit having oneor more processors and a topology information base. A Border GatewayProtocol (BGP) listener of the control unit that executes a routingprotocol to receive layer three (L3) network topology informationdefining routes to endpoints of a network that includes an autonomoussystem that includes the ALTO server. A PID generator of the controlunit that aggregates the endpoints into a set of one or more subsets oftopological groupings (PIDs), wherein each PID is associated with adifferent subset of the endpoints, wherein the BGP listener receives atopology information advertisement that specifies one or more routes andincludes network address information identifying one or more of theendpoints, wherein the BGP listener stores the one or more routes to thetopology information base, and wherein the PID generator aggregates theidentified endpoints into a first one of the set of PIDs. The ALTOserver also includes a network map module of the control unit thatgenerates an ALTO network map that includes a PID entry to describe eachof the PIDs, and a client interface that sends the ALTO network map toan ALTO client.

In another embodiment, the invention is directed to an application-layertraffic optimization (ALTO) server comprising a control unit having oneor more processors. An interface of the control unit that receives firstinter-AS network map and a first inter-AS cost map for a firstautonomous system, wherein the first inter-AS network map comprises afirst set of one or more local and remote subsets of topologicalgroupings (PIDs), wherein each local and remote PID of the firstinter-AS network map is associated with a different subset of endpointsof a network, wherein the local PIDs of the first inter-AS network mapspecify network address prefixes of the first autonomous system andremote PIDs of the first inter-AS network map specify network addressprefixes of a second autonomous system, wherein the first inter-AS costmap specifies ALTO costs for pairs of PIDs of the first inter-AS networkmap, wherein the interface receives a second inter-AS network map forthe second autonomous system, wherein the second inter-AS network mapcomprises a second set of one or more local and remote PIDs, whereineach local and remote PID of the second inter-AS network map isassociated with a different subset of the endpoints of the network,wherein the local PIDs of the second inter-AS network map specifynetwork address prefixes of the second autonomous system and remote PIDsof the second inter-AS network map specify network address prefixes ofthe first autonomous system, wherein the second inter-AS cost mapspecifies ALTO costs for pairs of PIDs of the second inter-AS networkmap. The ALTO server also comprises a network map module of the controlunit that generates a master ALTO network map for the network based atleast on the first inter-AS network map and the second inter-AS networkmap, and a client interface of the control unit that sends the masterALTO network map to an ALTO client.

The details of one or more embodiments of the invention are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating an example network thatdynamically generates and updates, using advertised routing information,network and cost maps in the manner described herein for use in anApplication-Layer Traffic Optimization (ALTO) service.

FIG. 2 is a block diagram illustrating an example graph that representsa combined ALTO inter-AS network and cost map that are dynamicallygenerated by an ALTO server for a network according to the describedtechniques.

FIG. 3 is a block diagram illustrating a network comprising ALTO serversthat perform federated ALTO techniques described herein.

FIGS. 4A-4B are block diagrams illustrating an example graphs thatrepresents a partial combined master network and cost map for a networkthat is generated by a master ALTO server, in accordance with thedescribed techniques, from multiple partial combined inter-AS networkand cost maps for the network as generated by and from the perspectiveof respective ALTO servers.

FIG. 5 is a block diagram illustrating an example network comprisingALTO servers that perform federated ALTO techniques for neighboringautonomous systems in the manner described herein.

FIG. 6A is a block diagram illustrating an example graph that representsa partial combined intra-AS network and cost map for that is generatedby an ALTO server for an autonomous system according to the describedtechniques.

FIG. 6B is a block diagram illustrating an example graph that representsa partial combined master network and cost map generated for a networkin accordance with the techniques described herein.

FIG. 7 is a block diagram illustrating, in detail, an example ALTOserver that receives routing information and dynamically generatesnetwork and cost maps in accordance with the techniques describedherein.

FIG. 8 is a flowchart illustrating an example mode of operation of anALTO server for dynamically generating or modifying an inter-AS networkmap, according to the described techniques, for an autonomous systemserved by the ALTO server.

FIGS. 9A-9D present a flowchart that illustrates an example operation ofan ALTO server to dynamically generate or modify an inter-AS cost mapfor an autonomous system served by the ALTO server according to thetechniques described herein.

FIG. 10 is a flowchart illustrating an example operation of an ALTOserver to generate a master ALTO network map according to the techniquesset forth herein.

FIG. 11 is a flowchart illustrating an example operation of an ALTOserver to generate master ALTO network and cost maps according to thetechniques set forth herein.

DETAILED DESCRIPTION

FIG. 1 is a block diagram illustrating an example network 2 thatdynamically generates and updates, using advertised routing information,network and cost maps for use in an Application-Layer TrafficOptimization (ALTO) service. Network 2 comprises autonomous systems4A-4D (illustrated as “ASes 4A-4D” and collectively referred to hereinas “autonomous systems 4”) interconnected by external communicationlinks. The term “communication link,” as used herein, comprises any formof transport medium, wired or wireless, and can include intermediatenodes such as network devices. Network 2 may in some embodimentsrepresent the Internet or any other publicly accessible computernetwork, a private network, or a virtual private network (VPN), thattransports content for delivery to requesting devices. While describedwith respect to Internet Protocol networks, the techniques are alsoapplicable to other types of delivery networks, such as AsynchronousTransfer Mode (ATM) networks.

Each of autonomous systems 4 run one or more interior gateway protocols(IGPs), such as Open Shortest Path First (OSPF), Routing InformationProtocol (RIP), Intermediate System-to-Intermediate System (IS-IS),Interior Gateway Routing Protocol (IGRP), Enhanced IGRP (EIGRP), andInterior Border Gateway Protocol (iBGP), and each of autonomous systems4 includes a set of one or more routers operating within a singleadministrative domain according to a routing policy. Autonomous systems4 each have an identification number provided by an Internet registry orby an Internet service provider (ISP) that uniquely identifies theautonomous system to other autonomous systems. In some instances, theidentification number may be drawn from a private identifier numberspace and therefore unique only within a private network comprising ASes4. In various embodiments, each of autonomous systems 4 may represent aservice provider network, an enterprise or campus network, a contentaccess network (CAN), or a content delivery network (CDN), for example.In addition, one or more service providers, content provider, orenterprise/campus network administrators may administer any one or moreof autonomous systems 4.

Routers of autonomous systems 4 execute an Internet Protocol (e.g., IPv4or IPv6) to route packets from a source network addresses to destinationnetwork addresses, and each of autonomous system 4 offers network packetdelivery to a network (or subnet) of one or more endpoints identified bya network address prefix that encompasses the network address rangedefined by the network addresses of endpoints. For example, AS 4B-4Doffer packet delivery to/from respective remote network address prefixes21A-21C (“remote prefixes 21”), while AS 4A offers packet deliveryto/from local network address prefixes 20A-20D (“local prefixes 20”).The terms “remote” and “local” with respect to the prefixes refer to thenetwork perspective of AS 4A, illustrated in greater detail that ASes4B-4D. The various routers illustrated in autonomous system 4A areinterconnected by internal communication links.

An AS that offers packet delivery to a prefix is the “originatingdomain” for the prefix, also known as the origin AS, and the BGP routingprotocol running in all autonomous systems 4 propagates theidentification number of the origin AS for the prefix as reachabilityinformation for the prefix. As a result, autonomous systems 4 routepackets destined for an endpoint having a network address that is withina particular prefix to the origin AS for the prefix. For instance,autonomous systems 4A-4C route packets destined for an endpoint ofprefix 21C to AS 4D.

Host 10 accesses AS 4A to issue content requests to, e.g., other hostsor CDN nodes located in any of autonomous systems 4, and to receiveapplication-related content for hosted applications. Host 10 mayrepresent, for example, a workstation, desktop computer, laptopcomputer, cellular or other mobile device, Personal Digital Assistant(PDA), gaming console, television set-top box, or any other devicecapable of accessing a computer network via a wireless and/or wiredconnection. Host 10 has a network address within local prefix 20C and isthus directly served by internal router 8B of AS 4A. In someembodiments, host 10 is a member of a customer network served by AS 4A.

The other devices (not shown in FIG. 1) to which host 10 issues contentrequests may be served by any of ASs 4A-4D. For example, host 10 mayissue a content request to a CDN node having a network address withinremote prefix 21B served by AS 4C. As another example, host 10 may issuea content request to an additional host having a network address withinlocal prefix 20A and executing a peer-to-peer (P2P) application forexchanging content among the various hosts, including host 10, whichalso execute the P2P application.

In the illustrated embodiment, AS 4A includes autonomous system boundaryrouters 6A-6B (“ASBRs 6”) that connect AS 4A to ASes 4B, 4D,respectively, over one of communication links (ASBRs of ASes 4B-4D notshown for ease of illustration). ASBRs 6 execute an exterior gatewayprotocol (EGP) to exchange, in one of external peering sessions 11 withASBRs of ASes 4A and 4D, routing information for respective autonomoussystems 4. For example, ASBRs 6 provides routing information thatdescribes an internal topology of autonomous system 4A and/orreachability of local prefixes 20. Additionally, ASBRs 6 receive routinginformation that describes reachability of remote prefixes 21 via ASes4B-4D. In some instances, ASBRs 6 may receive routing informationoriginated by one of ASes 4B-4D that describes an internal topology ofthe originating autonomous system.

Routing information for AS 4A outputted by one of ASBRs 6 in a peeringsession typically includes topology information received from one ormore interior routing protocol speakers of autonomous system 4Aexecuting an IGP, such as Internal BGP (iBGP), or received in one ofexternal peering sessions 11 from another one of ASes 4. Topologyinformation may also include administratively configured routes or otherinformation on ASBRs 6. The EGP used for external peering sessions 11may comprise, for instance, Exterior Border Gateway Protocol (BGP). Eachexternal peering session 11 may comprise a Transmission Control Protocol(TCP) session.

Autonomous system 4A includes reachability protocol speakers that peerwith one another to internally advertise topology information, e.g.,routes, for local prefixes 20 and remote prefixes 21 to other routerswithin AS 4A. Reachability protocol speakers of AS 4A include ASBRs 6,route reflector 17, and internal router 8B. ASBRs 6 and internal router8B each establish a peering session 9 with which to exchange routes withroute reflector 17. Route reflector 17 is a reachability protocolspeaker that re-advertises (or “reflects”) routes received from othergateway protocol speakers to enable the reachability protocol speakersto avoid forming a full mesh of peering sessions 9. However, inembodiments of network 2 that do not include route reflector 17, thereachability protocol speakers may form a full mesh of peering sessions.The reachability protocol with which reachability protocol speakersadvertise routes may comprise, for example, the Interior Border GatewayProtocol (IBGP). Topology information advertisements may comprise, forexample, route advertisements such as IBGP UPDATE messages. In general,a topology information advertisement associates a prefix with a NEXT_HOPfor the prefix and a list of autonomous systems that must be traversedto reach the prefix (“AS_PATH” in IBGP UPDATE messages).

The service provider or other administrator for AS 4A deploysApplication-Layer Traffic Optimization (ALTO) server 12 to AS 4A toprovide an application-layer traffic optimization service overautonomous systems 4. The application-layer traffic optimization may insome instances conform to the ALTO protocol. In general, the ALTOservice enables service and/or content providers to influence the nodeselection process by applications to further service/content providerobjectives, which may include improving a user experience by selectingthe most geographically proximate serving node to requesting host 10,reducing transmission costs to the provider, load balancing,service-level discrimination, accounting for bandwidth constraints,decreasing round-trip delay between host 10 and the serving node, andother objectives. Further details regarding the use of an ALTO servicein CDNs may be found in R. Penno et al., “ALTO and Content DeliveryNetworks: draft-penno-alto-cdn-03,” Network Working Group, the InternetEngineering Task Force draft, March 2011, which is incorporated hereinby reference in its entirety. Furthermore, while generally describedwith respect to the ALTO service and ALTO servers as described inSeedorf et al., incorporated above, the techniques are applicable to anyform of application-layer traffic optimization.

ALTO server 12 generates a network map and cost map for network 2 fromthe perspective of the ALTO server and provides these maps to ALTOclients in ALTO maps update message 13, such as ALTO client 18 of host10. A network map contains network location identifiers, or PIDs, thateach represents one or more network devices in a network. In general, aPID may represent a single device or device component, a collection ofdevices such as a network subnet, one of ASes 4, or some other grouping.A cost map contains cost entries for pairs of PIDs represented in thenetwork map and an associated value that represents a cost to traverse anetwork path between the members of the PID pair. The value can beordinal (i.e., ranked) or numerical (e.g., actual). ALTO client 18 ofhost 10 uses the network map and cost map to determine an optimalendpoint for use by an application executing on host 10. For example,host 10 may execute a P2P application that requires particular contentfrom a peer of the P2P network. ALTO client 18 of host 10 determines,from the network map and cost map, to determine an optimal peer fromwhich the P2P application may request and download the content. In someembodiments, host 10 represents a request router that receives contentrequests from client applications executing on nodes of network 2,determines an optimal server for the requesting clients using thenetwork map and cost map provided by ALTO server 12, and returns anetwork address or other identifier for the optimal servers to therequesting nodes. In still further embodiments, host 10 executes aclient of a client-server application that performs one of thetechniques described above. Further details regarding generating networkand cost maps for a multi-domain network are found in Penno et al., U.S.patent application Ser. No. 12/861,645, entitled “APPLICATION-LAYERTRAFFIC OPTIMIZATION SERVICE SPANNING MULTIPLE NETWORKS,” filed Aug. 23,2010, the entire contents of which are incorporated herein by reference.Additional details regarding ALTO map updates are found in Raghunath etal., U.S. patent application Ser. No. 12/861,681, entitled“APPLICATION-LAYER TRAFFIC OPTIMIZATION SERVICE MAP UPDATES,” filed Aug.23, 2010, the entire contents of which are incorporated herein byreference.

In some embodiments, ALTO server 12 provides an endpoint cost service.In such embodiments, ALTO client 18 of host 10 (operating as a peer fora P2P application) provides a list of one or more endpoints and anidentifier for hosts 10 to ALTO server 12. In response, ALTO server 12uses network and cost maps generated in accordance with the techniquesdescribed herein to determine an optimal endpoint in the list ofendpoints received for the receiving host. ALTO server 12 returns theoptimal endpoint to ALTO client 18 for use by an application executingon host 10. In some embodiments of ALTO server 12 that implement anendpoint cost service, ALTO server 12 returns a list of the endpoints ina rank ordering according to cost or returns a list of the endpointswith associated costs for each endpoint.

ALTO server 12 may comprise, for example, a high-end server or otherservice device, a content indexer for a P2P application, or a servicecard or programmable interface card (PIC) insertable into a networkdevice, such as a router or switch. ALTO server 12 may operate as anelement of a service plane of a router to provide ALTO services inaccordance with the techniques of this disclosure. Additional detailsregarding providing ALTO services as an element of a service plane of arouter are found in Raghunath et al., incorporated above.

In accordance with the techniques described herein, ALTO server 12establishes peering session 9, which may comprise an IBGP session, withroute reflector 17 of AS 4A. In this way ALTO Server 12 receives, inpeering session 9, routing information for AS 4A originated or forwardedby the reachability protocol speakers of AS 4A. In this instance, ALTOserver 12 is a passive reachability protocol listener that receivesrouting information reflected by route reflector 17. That is, in thisexample, because ALTO server 12 does not (in its capacity as an ALTOserver) originate or forward routes, route packets, or perform othersuch routing functions, ALTO server 12 merely receives routinginformation. Peering session 9 may comprise a Transmission ControlProtocol (TCP) session between route reflector 17 and ALTO server 12. Ininstances that do not include a route reflector, ALTO server 12 mayestablish peering session 9 to form a full protocol mesh with each ofthe reachability protocol speakers, e.g., ASBRs 6 and internal router8B.

In accordance with the techniques described herein, ALTO server 12generates an intra-AS ALTO network map for AS 4A using routinginformation received in peering session 9. An intra-AS network mapincludes prefixes that constitute or are served by AS 4A (i.e.,originated by AS 4A) aggregated by ALTO server 12 into one or PIDs. Theintra-AS network map does not include any prefixes originated externalto AS 4A.

In some instances, an administrator or other entity may configurereachability protocol speakers, including ASBRs 6 and internal router8B, to incorporate a prefix attribute into routing information outputtedin peering sessions 9. In instances where the reachability protocol isIBGP, the prefix attribute may comprise a BGP Community Attribute or BGPExtended Community Attribute. An AS 4A administrator, or another entity,assigns within the corresponding one of ASBRs 6 and/or internal router8B, a prefix attribute to one or more prefixes 20 for which thereachability protocol speaker originates or forwards routinginformation. For each prefix 20 typed in this manner, the reachabilityprotocol speaker adds the prefix attribute to a topology informationadvertisement that includes topology information that traverses ororiginates with the respective reachability protocol speaker and thatidentifies the prefix.

For example, an administrator may configure internal router 8B toincorporate a particular prefix attribute (e.g., “PREFIX_1”) into afirst topology information advertisement that advertises prefix 20C andinto a second topology information advertisement that advertises prefix20D. As another example, an administrator may configure internal router8B to incorporate a first particular prefix attribute (e.g., “PREFIX_1”)into a first topology information advertisement that advertises prefix20C and into a second topology information advertisement that advertisesprefix 20D. The administrator may additionally configure internal router8B to incorporate a second particular prefix attribute (e.g., “CDNNODE”) into the second topology information advertisement to identifythe range of network addresses defined by prefix 20D as includingendpoints that are CDN nodes of a CDN. Internal router 8B thengenerates/modifies and outputs topology information advertisements inaccordance with the specified configuration to route reflector 17 in apeering session 9. ALTO server 12 therefore receives topologyinformation advertisements that may include one or more prefixattributes for advertised prefixes 20.

A prefix attribute in a topology information advertisement may comprisea string, bitstring, or integer, for instance. Further details regardingusing prefix attributes of topology information advertisements tospecify endpoint types in an ALTO context may be found in Medved et al.,U.S. patent application Ser. No. 12/982,153, entitled “DYNAMICALLYGENERATING APPLICATION-LAYER TRAFFIC OPTIMIZATION PROTOCOL ENDPOINTATTRIBUTES,” filed Dec. 30, 2010, the entire contents of which areincorporated by reference herein.

ALTO server 12 includes one or more network map policies that specifyPID aggregation or PID attributes for topology information received intopology information advertisements in a peering session 9. For example,the network map policies may define mappings of prefix attributesincorporated within topology information advertisements to PIDattributes. A PID attribute value may be different than the prefixattribute value to which it is mapped. As another example, the networkmap policies may define mappings of prefix attributes incorporatedwithin topology information advertisements to specified PID identifiersto direct ALTO server 12 to aggregate one or more prefixes tagged with aparticular prefix attribute into the specified PID. In some instances,network map policies that specify PID aggregation may include additionalinformation that defines a cost between PIDs. The specified cost maycomprise a constant value or a formula for computing a cost based on oneor more parameters.

When ALTO server 12 receives topology information advertisements, theALTO server dynamically generates or modifies an intra-AS network map inaccordance with the network map policies described above. In one exampleimplementation, ALTO server 12 generates and/or updates PIDs of anintra-AS network map according to the following rules that reference thenetwork map policies. First, if the advertised prefix originates fromoutside of AS 4A, ALTO server 12 ignores the advertised prefix.

For an advertised prefix that originates with AS 4A, if the topologyinformation advertisement that carries the prefix includes a prefixattribute that maps to a specified PID within an ALTO map policy, thenALTO server 12 adds the prefix to the specified PID in the network map.

If a prefix attribute is not specified in any of the network mappolicies of ALTO server 12, the ALTO server creates/modifies a PIDhaving various prefixes associated with the same NEXT_HOP attribute intopology information advertisements for the prefixes. In some instances,ALTO server 12 may receive from multiple reachability protocol speakersdifferent topology information advertisements for a particular prefixthat each specifies a different NEXT_HOP attribute for the prefix. Insuch instances, ALTO server 12 first selects one of the advertisements(e.g., one of the routes) according to a decision process, such as theBGP decision process described in Rekhter et al., “A Border GatewayProtocol 4 (BGP-4),” Request for Comments 4271, January, 2006, section9.1 of which is incorporated by reference herein. In some instances,route reflector 17 performs the decision process prior to providingtopology information advertisements in peering session 9 to ALTO server12. The ALTO server 12 then uses the NEXT_HOP attribute for the selectedtopology information advertisement to aggregate the prefix therein withother prefixes also associated with the same NEXT_HOP attribute inrespective topology information advertisements (provided theadvertisements do not include a prefix attribute specified in a networkmap policy). In this way, ALTO server 12 groups the prefixes accordingto the next hop router for the prefixes when network map policies of theALTO server do not associate the prefixes to a PID or PID attribute.

For received topology information advertisements that do not fit any ofthe above categories yet originate with AS 4A and include one or moreprefix attributes that map to one or more PID attributes in a networkmap policy, ALTO server 12 aggregates into PIDs advertised prefixesassociated in the advertisements with the same set of prefix attributesand also with the same NEXT_HOP attribute. According to this rule, ALTOserver 12 may group into separate PIDs nodes that are both topologicallyproximate and that also exhibit similar functionality (e.g., CDN nodesattached to AS 4A at the same NEXT_HOP). In some instances, ALTO server12 may perform the decision process described above to select one ofmultiple topology information advertisements for use in network mapgeneration/modification. In some instances, however, route reflector 17performs the decision process prior to providing topology informationadvertisements in peering session 9 to ALTO server 12. In someinstances, ALTO server 12 may receive overlapping routes, as describedin Rekhter et al., incorporated above. In such instances, ALTO server 12may append the advertised prefix to multiple PIDs, which is permittedaccording to Alimi et al., incorporated above.

In addition to the dynamic PID aggregation process, ALTO server 12dynamically assigns PID attributes to PIDs of the intra-AS network mapaccording to network map policies that define mappings of prefixattributes incorporated within topology information advertisements toPID attributes. ALTO server 12 also specifies for each PID in theintra-AS network map, as a PID attribute, the NEXT_HOP for the PIDprefixes.

Application of the above rules by ALTO server 12 to topology informationadvertisements produces an intra-AS network map that reflects a currenttopology of AS 4A. That is, the intra-AS network generated/updated bythe ALTO server 12 includes PIDs dynamically aggregated and PIDattributes dynamically assigned in accordance with the techniquesdescribed above. ALTO server 12 provides the intra-AS network map toALTO client 18 in ALTO maps update message 13 for use by host 10 in nodeselection.

Routers of AS 4A, including ASBRs 6 and internal routers 8A-8B, executean interior gateway protocol (IGP) to disseminate routing informationthat allows the routers to select routes between any two nodes on acomputer network. One type of routing protocol, referred to as a linkstate protocol, allows routers to exchange and accumulate link stateinformation, i.e., information describing the various communicationlinks that interconnect routers within the AS 4A. With a typical thelink state routing protocol, the routers exchange information related toavailable interfaces, metrics and other variables associated withnetwork links. This allows a router to construct its own topology or mapof the network. Metrics may include, for example, latency, linkthroughput, link availability and reliability, path length, load, andcommunication cost (i.e., price). These metrics are typically expressedas simple integers.

Link state protocols include OSPF and IS-IS. Through application of thelink state protocol, the routers exchange link information with otheradjacent routers via link state advertisements (LSAs). A routergenerating an LSA typically floods the LSA throughout the network suchthat every other router receives the LSA. In this way, the receivingrouters may construct and maintain their own network topologies in arouting table (e.g., a link-state database (LSDB)) using the linkinformation exchanged via the LSAs.

Another type of routing protocol, referred to as a distance vectorrouting protocol, allows routers to exchange “vectors” of routinginformation that include, in each vector, a distance and direction. Thedistance refers to a metric, while the direction specifies a next hoprouter for the route advertised by the vector. In general, each routerlearns routes from neighboring routers and advertises routes from itsown perspective. Distance vector protocols include, for example, RoutingInformation Protocol (RIP), Interior Gateway Routing Protocol (IGRP),and Enhanced IGRP (EIGRP).

ALTO server 12 operates as a passive IGP listener by peering withinternal router 8B in IGP peering session 7. That is, ALTO server 12receives routing information from internal router 8B in IGP peeringsession 7 but does not originate or forward routing information, becauseALTO server 12 does not route packets (in its capacity as an ALTOserver). In some instances, internal router 8B may set an overload (OL)bit in link-state advertisements (LSAs) to ALTO server 12 to prevent theALTO server from returning routing information to internal router 8B.

IGP peering session 7 may represent, for example, an OSPF neighborrelationship (or “adjacency”) or may simply represent movement ofcurrent routing information from internal router 8B to ALTO server 12.In various configurations, ALTO server 12 may peer with other routers ofAS 4A in addition, or alternatively, to internal router 8B.

If routers of AS 4A execute a single-area OSPF (that is, if AS 4A is asingle-area OSPF network), ALTO server 12 may peer with any router of AS4A that executes OSPF to obtain the required routing information.Similarly, if routes of AS 4A execute Level 2 IS-IS, ALTO server 12 maypeer with any router of AS 4A that executes IS-IS to obtain the requiredrouting information.

In some instances, AS 4A may comprise a multi-area OSPF network. In suchinstances, ALTO server 12 establishes IGP peering session 7 with atleast one backbone (i.e., area 0) router to receive high-level routinginformation that describes links between the backbone and backbonerouters having at least one interface connected to the backbone. ALTOserver 12 may use the high-level routing information alone to estimateIGP metrics between next hops of PID pairs, where a next hop of a PID isa router that is a next hop for prefixes of the PID. PID next hops maybe specified in ALTO network maps as next hop attributes of PID entries.ALTO server 12 may establish additional IGP peering sessions with otherIGP routers in one or more non-backbone areas to receive lower-levelrouting information for links encompassed by the respective non-backbonearea. The ALTO server 12 may then use a combination of high-level andlower-level routing information to compute IGP metrics between next hopsof PID pairs. Each IGP peering session between ALTO server 12 and an IGProuter in a non-backbone area may comprise a virtual link such as, forexample, a Generic Routing Encapsulation (GRE) tunnel.

In some instances, AS 4A may comprise a Level 1/Level 2 IS-IS network.In these instances, ALTO server 12 establishes IGP peering session 7with at least one Level 2 router to receive high-level routinginformation that describes links between the backbone and backbonerouters having at least one interface connected to the backbone. ALTOserver 12 may use the high-level routing information alone to estimateIGP metrics between next hops of PID pairs. ALTO server 12 may establishadditional IGP peering sessions with other IGP routers in one or moreLevel 1 areas to receive lower-level routing information for linksencompassed by the respective Level 1 area. The ALTO server 12 may thenuse a combination of high-level and lower-level routing information tocompute IGP metrics between next hops of PID pairs. Each IGP peeringsession between ALTO server 12 and an IGP router in a non-backbone areamay comprise a virtual link such as, for example, a Generic RoutingEncapsulation (GRE) tunnel. In this instance, the remote Level 1 orLevel 2 router supports configuration of an IS-IS adjacency over a GREtunnel interface.

In some instances, ALTO server 12 receives, in peering session 9 withroute reflector 17, traffic engineering data distributed by BGP speakersof AS 4A and/or ASes 4B-4D. The traffic engineering data may includelink attributes such as local/remote IP addresses, local/remoteinterface indices, metrics, link bandwidth, reservable bandwidth, perCoS class reservation state, preemption and Shared Risk Link Groups(SRLG). The traffic engineering data may be encoded within BGPadvertisements from the BGP speakers. Further details regardingexchanging traffic engineering data using BGP are described in U.S.Provisional Patent Appl. No. 61/449,499, incorporated above. In theseinstances, ALTO server 12 receives topology and routing information,including reachability and link information for links connectingautonomous systems 4 router pairs, from BGP speakers in other IGP areasand may therefore avoid IGP peering with internal router 8B to receiveIGP information for AS 4A. In this way, ALTO server 12 may have aunified interface to AS 4A and the broader network encompassing ASes 4.

Upon receiving routing information, ALTO server 12 uses the informationto computes routes and calculates costs between different next hop pairsof AS 4A, then assigns these costs as ALTO costs to PID pairs of theintra-AS network map that have respective next hop attributes thatcorrespond to the next hop pairs. In other words, for each PID pair ofthe intra-AS network map, comprised of a first PID having a first nexthop and a second PID having a second next hop, ALTO server 12 usesreceived routing information to compute a route between the routersreferred to by the first and second next hop values (e.g., IPaddresses), computes a path cost for the route using link metrics (ordistances), and assigns a function of the path cost as an ALTO cost forthe PID pair. The ALTO cost for a PID pair represents a cost to traverseAS 4A from the next hop of the first PID of the PID pair to the next hopof the second PID of the PID pair. ALTO server 12 may calculate separatecosts to traverse AS 4A from the first PID to the second PID (i.e.,“forward metric”) and from the second PID to the first PID (i.e.,“backward metric”).

For example, ALTO server 12 may receive a current LSDB from internalrouter 8B executing a link state routing protocol, apply a shortest pathfirst (SPF) algorithm to the LSDB to compute a shortest path tree for aPID of the intra-AS network map, and use path costs associated with thebranches of the shortest path trees to calculate ALTO costs between thePID and other PIDs of the intra-AS network map. As another example, ALTOserver 12 may build a routing table using routing information obtainedfrom internal router 8B by operating as a passive listener of a distancevector protocol. The ALTO server 12 uses the routes and distancesspecified in the routing table to calculate ALTO costs between the PIDand other PIDs of the intra-AS network map.

ALTO server 12 may include one or more ALTO cost policies that defineformulas for calculating ALTO cost values for a particular metric. Suchpolicies may incorporate other parameters, in addition to the IGPmetric, into the formulas. For example, ALTO server 12 may receivetraffic engineering parameters as configuration data or within extendedLSAs of OSPF, for instance. For example, ALTO server 12 may receive pathcosts that represent traffic engineering parameters encoded as NetworkLayer Reachability Information (NLRI) attributes of a BGP UPDATEmessage. In general, routers use traffic engineering parameters tocreate the traffic engineering database, which is used by ConstrainedShortest Path First (CSPF) to compute Multi-Protocol Label Switching(MPLS) Label Switched Paths (LSPs). ALTO cost policies may specifyincorporating information within the traffic engineering databaseregarding various links and paths interconnecting routers of AS 4A whencomputing ALTO costs for PID pairs of the intra-AS network map. Otherparameters for AS 4A incorporated by ALTO server 12 may include linkdelays or load on router interfaces for routers of AS 4A. Someparameters may be received from sources external to AS 4A, such asapplication or other content servers attached to AS 4A in one ofprefixes 20. These parameters may include load and response times forthe servers, for instance.

ALTO server 12 assembles the calculated ALTO cost values into anintra-AS cost map for AS 4A. The intra-AS cost map defines inter-PIDrouting costs for connections among the various PIDs of the intra-ASnetwork map. ALTO server 12 then provides the intra-AS cost map to ALTOclient 18 in ALTO maps update message 13. Using the intra-AS network mapand cost map provided by the ALTO server, application clients andcontent request routers (e.g., executing on host 10) select servingresources to minimize costs, as specified by the ALTO maps, betweencontent requesting clients and available resources of AS 4A.

In some instances, ALTO server 12 may generate different costs formultiple cost maps that reflect a particular service provider objective.For example, ALTO server 12 may generate a first intra-AS cost map thatspecifies ALTO costs calculated by the ALTO server to minimize delay.Such a cost map may improve the performance of voice applications, forexample, when provided to ALTO client 18 of host 10. ALTO server 12 maygenerate second intra-AS cost map that specifies ALTO costs calculatedby the ALTO server to maximize bandwidth. This cost map may improveperformance of video or other high-bandwidth applications.

In some embodiments, ALTO server 12 additionally generates ALTO networkand cost maps that incorporate additional elements of network 2 beyondAS 4A. ALTO server 12 generates these “inter-AS” network and cost mapsfrom the perspective of AS 4A, for that autonomous system encompassesALTO server 12, and routing information known to ASBRs 6 of AS 4A maybecome known to ALTO server 12. As stated previously, network 2 mayrepresent the Internet. In contrast to intra-AS network and cost maps,which may include a detailed rendering of application-relevant topologyand costs within AS 4A, inter-AS network maps may not include allInternet prefixes, and the division of such prefixes that are includedinto PIDs may be coarse-grained. Further, inter-AS cost maps may besparse due to limited external routing information available to AS 4A.As with intra-AS cost maps, ALTO server 12 may generate different costsfor multiple inter-AS cost maps that reflect a particular serviceprovider objective.

ASBRs 6 execute an exterior gateway protocol (e.g., BGP) to exchange, inone of external peering sessions 11 with ASBRs of ASes 4A and 4D,routing information for respective autonomous systems 4. The exteriorgateway protocol is hereinafter described with respect to exterior BGP(BGP). ASBRs 6 thus receive topology information advertisements in theform of BGP UPDATE messages from ASBRs of ASes 4A and 4D that includeroutes to prefixes 21. A BGP UPDATE message associates one of prefixes21 with a NEXT_HOP for the prefix and a list of autonomous systems thatmust be traversed to reach the prefix (the AS_PATH). The AS_PATH andidentifiers for prefixes 21 may be expressed within BGP UPDATE messageswithin Network Layer Reachability Information (NLRI). ASBRs 6redistribute routing information received in BGP UPDATE messages to anIGP via peering sessions 9. As stated above, the IGP may comprise IBGPand in such instances peering sessions 9 comprise IBGP peering sessions.In the illustrated embodiment, route reflector 17 re-advertises therouting information to ALTO server 12. As a result of internaldistribution of externally originated routing information by IGP routersof AS 4A, ALTO server 12 receives the routing information that includesroutes to prefixes 21 of ASes 4B-4D. ALTO server 12 may also beadministratively configured with routing information, such as routes toprefixes 21, as well as metrics for inter-AS links (e.g., a cost for acommunication link that links AS 4B to AS 4C, or a default cost for allinter-AS links). ALTO server 12 may comprise a routing table with whichto store routing information.

In some instances, ASBRs 6 receive traffic engineering data advertisedby BGP speakers of ASes 4B-4D and encoded with BGP messages. ASBRs 6provide these messages to route reflector 17, which re-advertises thetraffic engineering data to ALTO server 12. As a result, ALTO server 12may receive respective intra-AS and/or inter-AS routing and topologyinformation for ASes 4B-4D.

ALTO server 12 uses current intra-AS and inter-AS routing informationreceived in a peering session 9 (or administratively configured) togenerate/update an inter-AS network map for network 2. In someinstances, ALTO server 12 generates/updates the inter-AS network map byfirst determining an optimal route for prefixes 20, 21 for which theALTO server 12 is aware. For local prefixes 20, ALTO server 12 performsthe techniques described above for generating inter-AS network and costmaps. As a result, an inter-AS network map generated by ALTO server 12may comprise the substance of an intra-AS network map for AS 4Agenerated as in the manner described above.

To aggregate prefixes 21 originated in remote ASes 4B-4D into PIDs, ALTOserver 12 aggregates into a separate PID all prefixes 21 that have,according to the routing information, the same AS_PATH attribute andNEXT_HOP attribute. In other words, ALTO server 12 aggregates into aseparate PID any prefixes 21 that are reachable by the same route(AS_PATH) and are also advertised within AS 4A by the same one of ASBRs6 (NEXT_HOP). In the example embodiment, ALTO server 12 assigns each ofprefixes 21 to a separate PID, because each of the prefixes have adifferent AS_PATH. In various embodiments, however, multiple differentprefixes advertised in separate topology advertisements may be assignedto the same PID according to the above aggregation rules. ALTO server 12assembles the PIDs into an inter-AS network map for network 2.

Dynamically generating an inter-AS cost map for network 2 from theperspective of AS 4A (and ALTO server 12) may require inter-AS costs,i.e., a cost between PIDs with prefixes located in different ones ofASes 4. ALTO server 12 may be configured with a policy or otherconfiguration data with inter-AS costs. In some embodiments, theinter-AS cost applied by ALTO server 12 is identical for all pairs ofASes 4. In other words, the inter-AS cost is a default inter-AS cost. Insome embodiments, however, ALTO server 12 may include specific inter-AScosts for one or more pairs of ASes 4. For example, ALTO server 12 maybe configured with a value for an inter-AS cost between ASes 4B and 4C.

A cost between two remote PIDs (e.g., between a PID in AS 4B and a PIDin AS 4C) is deemed proportional to the number of inter-AS links betweenthe two remote PIDs when the inter-AS cost is a default value that islarger than the largest intra-AS cost. To determine the number ofinter-AS links between the two remote PIDs, ALTO server 12 reads theAS_PATH attribute of the two remote PIDs. The final autonomous systemidentification number in the AS_PATH attribute value for a PID is theautonomous system that serves the PID (i.e., the autonomous system thatoriginates advertisements for prefixes encompassed by the PID). Forexample, from the perspective of AS 4A, an AS_PATH for a PID includingprefix 21B comprises [(Identification number for AS 4B), (Identificationnumber for AS 4C)].

If the AS_PATH attribute for either of the two remote PIDs includes theidentification number for the autonomous system that serves the otherremote PID, ALTO server 12 computes the inter-AS cost as the product ofthe default inter-AS cost (C) and the number of inter-AS links,according to the AS_PATH attribute, that must be traversed to reach thePID from the other remote PID. In the above example, according to theAS_PATH attribute for the PID comprising prefix 21B of AS 4C, a PIDcomprising prefix 21A of AS 4B traverses one inter-AS link to reach thePID comprising prefix 21B. The inter-AS cost between the two PIDs istherefore equal to 1×C.

ALTO server 12 computes costs in this manner between each of the remotePIDs represented in the inter-AS network map and stores the costs into acorresponding inter-AS cost map. In some instances, ALTO server 12includes a policy or other configured data that specifies actual, ratherthan default, inter-AS costs between pairs of ASes 4. In such instances,ALTO server 12 may sum the inter-AS costs between pairs of ASes 4represented in an AS_PATH attribute of a remote PID to compute a totalcost between two remote PIDs.

To determine costs between two PIDs each encompassing one or more oflocal prefixes 20 (i.e., “local” PIDs from the perspective of AS 4A),ALTO server 12 performs the techniques described above for generatingintra-AS cost maps and incorporated computed costs for local PID pairsinto the inter-AS cost map. As a result, an inter-AS cost map generatedby ALTO server 12 may comprise the substance of an intra-AS cost map forAS 4A generated as in the manner described above.

For a mixed local-remote PID pair combination, ALTO server 12supplements the inter-AS cost from AS 4A to the remote PID with theintra-AS cost from local PID to the NEXT_HOP of the remote PID. In theillustrated embodiment, the NEXT_HOP of the remote PID is one of ASBRs6. In other words, ALTO server 12 combines the inter-AS cost with theintra-AS (IGP) cost to determine a total cost to traverse a route fromthe local PID of the PID pair to the remote PID. The inter-AS cost fromAS 4A, where ALTO server 12 applies the default inter-AS cost, C, tointer-AS links, is the product of the length of the AS_PATH attributevalue (i.e., the number of ASes in the AS_PATH) for the remote PID andC. For example, the inter-AS cost between a local PID and a remote PIDcomprising prefix 21B is equal to 2×C, for the AS_PATH includes AS 4B,4C and thus has length two.

ALTO server 12 sums the intra-AS and inter-AS cost to determine a totalcost, then add the total cost for the local-remote PID pair to theinter-AS cost map for network 2. In some instances, ALTO server 12 mayinclude ALTO cost policies that define formulas for calculating totalcost values based on inter-AS and intra-AS costs. Such policies mayincorporate other parameters, in addition to these costs, as describedabove with respect to using ALTO cost policies in the exclusive intra-AScontext.

Dynamically generating and updating ALTO network and costs maps with anALTO server using routing information received from network elementssynchronizes the maps to an ever-changing network environment. As aresult, the network and cost maps provided by ALTO server 12 to ALTOclient 18 may reflect recent updates to the network topology and/orutilization and may thus improve node selection and increase performanceby one or more applications of host 10. Moreover, automatically creatingnetwork and cost maps may reduce an ALTO server 12 configuration burdenon the administrator of AS 4A, making an ALTO server implementationviable in a large-scale service provider environment. The configurationburden may be, rather, distributed to respective administrators of thevarious ASes 4. In this way, the administrator “close to” a particularone of subnets 20, 21 can be responsible for the treatment of thatsubnet by ALTO server 12 and ALTO client 18. Because the respectiveadministrators of remote ASes 4B-4D typically have a fuller knowledge ofthe configuration of the remote ASes than does the administrator of AS4A, the techniques may thus improve subsidiarity among network entitiesand operators that cooperate to facilitate content distribution, therebyrelieving configuration pressures on the administrator of ALTO server12.

FIG. 2 is a block diagram illustrating an example graph 25 thatrepresents a combined ALTO inter-AS network and cost map for network 2of FIG. 1 that are dynamically generated by ALTO server 12 according tothe described techniques. PIDs 22A-22F (“PIDs 22”) each encompass one ormore prefixes and thus represent the PIDs of an inter-AS network map fornetwork 2. Edges interconnecting PIDs and each annotated with aninter-PID cost represent an inter-AS cost map for network 2.

Performing the techniques described above with respect to FIG. 1, ALTOserver 12 aggregates prefix 20A into PID 22A because the next hop forprefix 20A is ASBR 6A. Similarly, ALTO server 12 aggregates bothprefixes 20C, 20D into PID 22C because the shared next hop for theseprefixes is internal router 8B. Topology advertisements originated byrespective ones of ASes 4B-4D include prefixes that are placed by ALTOserver 12 into a separate PID. In other words, in this instance, ALTOserver 12 aggregates all prefixes served by the same one of ASes 4B-4Dinto the same PID. For example, PID 22E includes prefix 21B advertisedby AS 4C and, in other configurations, would further include any otherprefixes advertised by AS 4C.

ALTO server 12 computes intra-AS costs for local PIDs, i.e., PIDs thatencompass prefixes 20 served by AS 4A, using routing informationreceived in an IGP session. Graph 25 annotates intra-AS costs on edgesusing an instance of A_(i). For example, the intra-AS cost between localPID 22A and local PID 22B is A₃. Additionally, ALTO server 12 in thisinstance uses a default inter-AS cost, C, as the transit routing costbetween each pair of neighboring ASes 4. For example, a cost between PID22D (here aggregating AS 4B) and PID 22E (here aggregating AS 4C) is Cbecause the represented ASes 4B, 4C are neighbors. As another example, acost between PID 22E and PID 22A (the next hop attribute of which is thenext hop to AS 4B, i.e., ASBR 6A) is 2×C.

For a mixed local-remote PID 22 pair combination, ALTO server 12supplements the inter-AS cost from the next hop of AS 4A to the remotePID with the intra-AS cost from local PID to the NEXT_HOP of the remotePID. In this instance, ALTO server 12 sums the inter-AS cost andintra-AS costs values to compute a total inter-PID cost. For example, acost, C+A₁, between PID 22D and PID 22C is a sum of the cost, C, betweenPID 22D and PID 22A and the cost, A₁, between PID 22A and PID 22C.

Graph 25 does not include an edge to connect PID 22D and PID 22F becauseALTO server 12 does not receive routes that include an AS_PATHcomprising both AS 4B and AS 4D. ALTO server 12 is therefore unable todetermine the costs between remote AS 4B and remote AS 4D.

FIG. 3 is a block diagram illustrating network 36 comprising ALTOservers 38A-38C (“ALTO servers 38”) that perform federated ALTOtechniques described herein. Network 36 includes autonomous systems40A-40C (“ASes 40”) that each includes a respective one of ALTO servers38. Autonomous systems 40 are interconnected via external communicationlinks 44. Each of ASes 40 may represent an example embodiment of one ofautonomous systems 4 of FIG. 1. Each of ALTO servers 38 may represent anexample embodiment of ALTO server 12 of FIG. 1. Various combinations ofASes 40 may be under administrative control of one or moreadministrators or service providers.

Each of ALTO servers 38 performs dynamic network map generation andmodification techniques described in this disclosure to aggregateprefixes (not shown in FIG. 3) served by associated ASes 40 into one ormore of PIDs 42 and assemble the PIDs into an inter-AS network map and,in some instances, into an intra-AS network map. As illustrated, forexample, ALTO server 38A aggregates prefixes served by AS 40A into PIDs42A, 42B, prefixes of which are connected by an intra-AS communicationlink. That is, prefixes of PID 42A are connected by an inter-AScommunication link to prefixes of PID 42B. Each of ALTO servers 38additionally performs dynamic cost map generation and modificationtechniques described herein to produce an inter-AS cost map thatincludes costs for various combinations of local and remote PIDsassociated with the network maps produced by the ALTO server. As aresult, each of ALTO servers 38 produces local network and local costmaps that represent a topology of network 36 from the perspective of theassociated one of autonomous systems 40 for the ALTO server.

ALTO servers 38 federate with one another in an ALTO federation to shareinformation to foster fine PID prefix granularity throughout network 36and thereby improve node selection. ALTO server 38B is a master ALTOserver that, in addition to its local functions (i.e., generatingnetwork and cost maps from the perspective of AS 40B), generates masternetwork and cost maps for network 36 using the various local intra-ASand/or inter-AS network and cost maps generated by each of ALTO servers38. ALTO server 38B (hereinafter, “master ALTO server 38B”) may beadministratively configured as a master ALTO server 38B or may beelected during a negotiation between eligible ALTO servers 38. In someconfigurations, multiple ALTO servers 38 may operate as a master ALTOserver.

To enable master ALTO server 38B to determine, within the many networkmaps master ALTO server 38B generates and receives, the originating oneof autonomous systems 40 for each PID in the network maps, ALTO servers38 add an autonomous system identifier (“AS ID”) attribute to PIDs oftheir respective network maps. The autonomous system identifier maycomprise the registered identification number for the originating one ofASes 40 for each of the PIDs (including PIDs 42). In other words, eachof PID that encompasses a particular one or more prefixes is “tagged”with an AS ID for the one of ASes 40 that originated the prefixes. Eachof ALTO servers 38 may therefore tag PIDs in its network maps withdifferent AS IDs. For example, ALTO server 38A tags PIDs 42A, 42B in theinter-AS network map generated by the ALTO server with an AS ID for AS40A. In some instances, ALTO server 38A may additionally tag any remotePIDs of the inter-AS network map with AS IDs for the autonomous systemsthat originated prefixes of the remote PIDs.

Each one of local PIDs 42 in an inter-AS network map thus carries anidentity of the one of ASes 40 that includes the one of ALTO servers 38that generated the PID. Because the local perspective of each prefixincluded in one of PIDs 42 represents the most precise topologicalgrouping for the prefix, PIDs from the originating one of ASes 40 shouldbe migrated to the master network map. Put another way, by identifyingthe originating one of ASes 40 for each of PIDs 42, PIDs at the finestlevel of prefix granularity may be identified and selected by masterALTO server 38B for inclusion in a master network map. ALTO servers 38A,38C send their respective, inter-AS network and cost maps to ALTO server38B in respective upload messages 46A, 46B.

In some embodiments, rather than adding an AS ID attribute to each PIDin inter-AS network maps, each of ALTO servers 38 generate both intra-ASand inter-AS network maps. ALTO servers 38A, 38C then send theirrespective, network and cost maps to ALTO server 38B in respectiveupload messages 46A, 46B. In these embodiments, upload messages 46A, 46Badditionally include an AS ID for the one of ASes 40 that includes thesending one of ALTO servers 38A, 38C. For example, ALTO server 38A sendsinter-AS and intra-AS network maps, an inter-AS cost map, and an AS IDfor AS 40A in upload message 46A to master ALTO server 38B. When masterALTO server 38B receives respective upload message 46A, 46B from one ofALTO servers 38A, 38C in these embodiments, the master ALTO server 38Bidentifies local PIDs within the inter-AS network map by correlating theprefixes of PIDs within the inter-AS network map to prefixes of PIDswithin the intra-AS network map. When a prefix is included within a PIDof the intra-AS network map, any PID of the inter-AS network map thatalso includes the prefix is a local PID. Master ALTO server 38B thentags identified local PIDs with the AS ID received along with the localnetwork maps. This technique may reduce a size of upload messages 46.

ALTO servers 38A, 38C send their respective, local network and cost mapsto ALTO server 38B in respective upload messages 46A, 46B. Master ALTOserver 38B generates a local network and cost map for AS 40B. Responsiveto receiving local network and cost maps, master ALTO server 38Bgenerates the master network and cost map for the ALTO federation ofnetwork 36. Master ALTO server 38B may correlate perspectives from eachof the local network and cost maps received or generated into a single,consolidated master network and cost map. Master ALTO server 38B thensends the master network and cost maps to ALTO server 38A, 38C inrespective download messages 47A, 47B.

FIG. 4A is a block diagram illustrating an example graph 54 thatrepresents a partial combined master network and cost map for network 36of FIG. 3 that is generated by master ALTO server 38B, according to thedescribed techniques, from graphs 50A, 50B that represent partialcombined inter-AS network and cost maps for network 36 generated by andfrom the perspective of respective ALTO servers 38A, 38C. Graphs 54 and50A-50B are “partial” in that they do not include elements of AS 40B(for ease of illustration). In some instances, graphs 50A-50B includeadditional elements to incorporate the elements of AS 40B of FIG. 3. Insome instances, graph 54 includes additional elements to incorporate aperspective of ALTO server 38B and/or the elements of AS 40B included invarious instances of graphs 50A-50B.

ALTO server 38A generates an inter-AS network map from a perspective ofAS 40A that include the elements illustrated in graph 58. Specifically,the inter-AS network map includes local PIDs 42A, 42B. PID 42A has PIDidentifier “PID1” and encompasses prefix P1. PID 42B has PID identifier“PID2” and encompasses prefix P2. The inter-AS network map additionallyincludes remote PID 52A that, in this instance, represents anaggregation of prefixes of AS 40C that are advertised to AS 40A in, forexample, BGP UPDATE messages. These prefixes include P3, P4, and P5.ALTO server 38A generates an inter-AS cost map that includes cost mapentries for the inter-AS network map. Graph 50A illustrates computedinter-PID costs as arrows. For example, a cost from PID 42A to PID 52Ais 2C, the cost computed by ALTO server 38A according to the techniquesdescribed herein for traversing two inter-AS (or “transit”)communication links 44 between AS 40A and AS 40C. ALTO server 38Aadditionally computes an inter-PID cost, A1, for the PID pair <PID 42A,42B> using an IGP metric using the techniques of this disclosure.

ALTO server 38C generates an inter-AS network map from a perspective ofAS 40C in a similar manner. Although not shown in FIG. 4A, each of PIDs42A-42B, 42E-42F, and 52A, 52B may include an AS ID for the originatingone of ASes 40 for respective, encompassed prefixes. For example, localPID 42E may be tagged with an AS ID for AS 40C in the network maprepresented by graph 50B. As another example, remote PID 52A may betagged with an AS ID for AS 40C in the network map represented by graph50A.

In this example, all prefixes of AS 40C (that is, prefixes P3, P4, andP5) are advertised to AS 40A and aggregated into PID 52A by ALTO server38A. Similarly, all prefixes of AS 40A (this is, prefixes P1 and P2) areadvertised to AS 40C and aggregated in PID 52B by ALTO server 38C.

Master ALTO server 38B receives the inter-AS network and costs mapsrepresented by graphs 50A, 50B from respective ALTO servers 38A, 38C andgenerates the master network and cost maps represented by graph 54. Togenerate a master network map from multiple inter-AS network maps,master ALTO server 38B copies all local PIDs of the inter-AS networkmaps into the master network map. Each of ALTO servers 38 receives thefinest granular routing information for its respective one of ASes 40and therefore has the fullest information base with which to generatelocal PIDs and compute local inter-PID costs.

Additionally, master ALTO server 38B reconciles each remote PID in eachone of the inter-AS network maps with local PIDs in the inter-AS networkmap for the originating one of ASes 40 that advertises the prefixes ofthe remote PID. In other words, master ALTO server 38B intersects theprefixes of remote PIDs with prefixes of corresponding local PIDs forthe originating (i.e., remote) one of ASes 40 to facilitate the finestavailable level of PID granularity for the PIDs of the master networkmap. Considering both a local PID and a remote PID as respectivemathematical sets of prefixes, the resulting PIDs for a master networkmap consist of (1) a PID that includes the relative complement of theremote PID in the local PID (i.e., the set of prefixes in the local PIDbut not in the remote PID) and (2) the intersection of the remote PIDand the local PID (i.e., the set of prefixes in both the remote PID andthe local PID). However, if any of these resulting sets of prefixes isnull, master ALTO server 38B does not generate a corresponding PID forthe null set. Moreover, if any of these resulting sets is alreadyencompassed by a PID of the master network map, master ALTO server 38Bmay not create a second PID for the same prefix set.

Typically, because ALTO servers 38 generate few remote PIDs for a remoteAS, master ALTO server 38B simply copies to the master network map thelocal PIDs in the inter-AS network map for the originating one of ASes40 that advertises the prefixes of the remote. In some instances,however, master ALTO server 38B must reallocate prefixes of a local PIDof an inter-AS network map into two or more PIDs for inclusion in masternetwork map. Examples of these instances are described in detail belowwith respect to FIG. 4B.

In the illustrated example, master ALTO server 38B reconciles remote PID52A of graph 50A with local PIDs 42E-42F of graph 50B. Because PID 52Aincludes every prefix represented in PIDs 42E-42F, PIDs 42E-42Frepresent the finest level of granularity for the prefixes, arereachable from each of PIDs 42A-42B with identical costs, and are thuscopied by master ALTO server 38B directly to the master network map(represented by PIDs of graph 54).

As an example in the other network traffic direction, master ALTO server38B reconciles remote PID 52B of graph 50B with local PIDs 42A-42B ofgraph 50A. PID 52B includes every prefix represented in PIDs 42A-42B andis reachable from each of PIDs 42E-42F at identical cost. Master ALTOserver 38B therefore directly copies PIDs 42A-42B to the master networkmap (represented by PIDs of graph 54).

As seen in graph 64, master ALTO server 38B does not include remote PIDs52A, 52B in the master network map. Master ALTO server 38B only carriesover PIDs for prefixes originated in one of ASes 40 (i.e., local PIDs)into the master network map. In some instances, master ALTO server 38Bmay modify PID identifiers when copying a local PID into the masternetwork map. For example, PID 42A in both graph 60A and graph 64 has aPID identifier “PID1.” In some instances, master ALTO server 38B mayprovide a network PID identifier for PID 42A in graph 64.

To generate a master cost map from the multiple inter-AS network andcost maps provided by ALTO servers 38, master ALTO server 38B usesinter-PID costs computed from a perspective of an AS from which networktraffic will originate. For PID pairs in which both members of the pairare local to a particular one of the inter-AS network maps, master ALTOserver 38B uses the inter-PID costs specified in the correspondinginter-AS cost map. In the illustrated example, for instance, master ALTOserver 38B sets A1 as a cost between PIDs 42A, 42B of the master networkmap upon determining A1 as the cost between local PIDs 42A, 42B of theinter-AS network map represented by graph 50A. As in the inter-AS costmap, any PID pair of the master cost map may be associated with twounidirectional costs representing the costs to traverse a network inboth directions between the member PIDs of the PID pair.

For PID pairs in which different ASes 40 originate the member PIDs ofthe PID pair, for each network traffic direction, master ALTO server 38Buses the cost as specified by the one of ALTO servers 38 for therespective one of ASes 40 that originates the traffic. For example, toidentify the ALTO cost to traverse the network from PID 42A (includingprefix P1 of AS 40A) to PID 42E (including prefix P3 of AS 40C), masterALTO server 38B queries the inter-AS cost map provided by AS 40A todetermine the inter-PID ALTO cost between local PID 42A and remote PID52A (including prefix P3 of AS 40C). This inter-AS cost map isrepresented in graph 50A, which indicates this inter-PID ALTO cost is2C. Master ALTO server 38B sets the cost from PID 42A to 42E within themaster cost map to 2C.

In the other traffic direction, that is, from PID 42E to PID 42A, masterALTO server 38B queries the inter-AS cost map provided by AS 40C todetermine the inter-PID ALTO cost between local PID 42E and remote PID52B (including prefix P1 of AS 40A). Graph 50B that represents a partialinter-AS cost map provided by AS 40C indicates the cost is 2C. MasterALTO server 38B therefore sets the cost from PID 42E to 42A within themaster cost map to 2C.

Graph 54 represents all inter-PID costs as bi-directional arrows forease of illustration because, in the illustrated embodiment, inter-PIDcosts in both directions are equal. In some instances, a cost totraverse a network between any two PIDs in one direction differs fromthe cost to traverse a network between the PIDs in the reversedirection. As a result, the master cost map may include a respectivecost entry for each direction for the two PIDs.

FIG. 4B is a block diagram illustrating variant partial combined networkand cost maps of FIG. 4A for an embodiment of network 36 of FIG. 3 inwhich AS 40C does not advertise prefix P4 to AS 40A. Graph 64 of FIG. 4Brepresents a partial combined master network and cost map for network 36that is generated by master ALTO server 38B, according to the describedtechniques, from graphs 60A, 60B that represent partial combinedinter-AS network and cost maps for network 36 generated by and from theperspective of respective ALTO servers 38A, 38C.

In this illustrated embodiment, unlike the embodiment illustrated inFIG. 4A, remote PID 62A of graph 60A does not include prefix P4 becauseAS 40C does not advertise prefix P4 to AS 40A. Autonomous system 40Acomprises ALTO server 38A that generates the partial inter-AS networkand cost maps represented by graph 60A.

Because prefix P4 of AS 40C is not advertised and therefore notreachable from AS 40A, master ALTO server 38B allocates prefixes P4, P5of PID 42F to separate PIDs 66A, 66B for the master network maprepresented by graph 64. This operation comprises both the intersectionand relative complement operations described above with respect to FIG.4A. That is, master ALTO server 38B creates for the master network map(1) PID 66A encompassing the set of prefixes that is an intersection ofthe set of prefixes of remote PID 62A of graph 60A and the set ofprefixes of local PID 42F of graph 60B (i.e., prefix P5), and (2) PID66B encompassing the set of prefixes that is a relative complement ofthe set of prefixes of remote PID 62A of graph 60A in the set ofprefixes of local PID 42F of graph 60B (i.e., prefix P4).

Master ALTO server 38B sets costs in the master cost map that accordwith the costs of the inter-AS cost maps. Because ALTO server 38Caggregates prefixes P4, P5 into a single PID 42F, the ALTO cost betweenthese prefixes is zero. Master ALTO server 38B therefore sets the ALTOcost between PIDs 66A, 66B that each encompass one of prefixes P4, P5 tozero in the network cost map represented by graph 64. Similarly, theALTO cost between PIDs 42E, 42F is set to B1 according to graph 60B.Master ALTO server 38B therefore sets the ALTO cost between PIDs 42E,66A and between PIDs 42E, 66B to B1 in the network cost map representedby graph 64, for PIDs 66A and 66B include reallocated prefixes of PID44F.

Because there is no available path from prefixes of AS 40A to prefix P4of AS 40C, the ALTO costs from PIDs 42A, 42B to PID 66B is set toinfinity in the master cost map. This is illustrated in graph 64 by theabsence of a directional arrow from either of PIDs 42A, 42B to PID 66B.However, because AS 40A prefixes P1, P2 to AS 40C, a directional arrowillustrating cost 2C connects PID 66B to each of PIDs 42A, 42B torepresent these costs in the master cost map generated by master ALTOserver 38B. Some instances of master ALTO server 38B may set the ALTOcost from PID 66B to each of PIDs 42A, 42B to infinity because mostapplications require bi-directional communication and that an ALTOclient should not therefore select either of PIDs 42A, 42B to serve aclient in PID 66B.

Various other embodiments of network 36 of FIG. 3 may require PID prefixreallocation from inter-AS network maps by master ALTO server 38B whengenerating the master network map for network 36. For example, in someembodiments, two or more remote PIDs of a first inter-AS network map maytogether encompass two or more prefixes that are aggregated at theoriginating one of ASes 40 for these prefixes into a single local PID ofa second inter-AS network map for the originating AS. This may occurwhere, for example, traffic engineering parameters specify a differentautonomous system path (AS_PATH) for reaching each of the remote PIDsfrom local PIDs of the first inter-AS network map. In other words, theprefixes in the remote PIDs are associated with different AS_PATHlengths from the autonomous system that includes the one of ALTO servers38 that generated the first inter-AS network map.

In this instance, master ALTO server 38B reallocates the prefixes of thesingle local PID of the second inter-AS network map into two or moremaster network map PIDs that each encompasses a different set of theprefixes, grouped according to similar AS_PATH lengths as specified bythe two or more remote PIDs of the first inter-AS network map. In thisway, master ALTO server 38B aggregates all prefixes from remote PIDs ofthe first inter-AS network map that have the same AS_PATH length intothe same PID for the master network map. Because the various prefixesare aggregated into a single PID in the second inter-AS network map, theALTO cost between these prefixes is zero. Master ALTO server 38Btherefore sets the ALTO cost between the various pairs of the two ormore master network map PIDs generated in this manner to zero. MasterALTO server 38B sets the ALTO cost to the two or more “split” masternetwork map PIDs from the PIDs of the AS of the first inter-AS networkmap according to the cost specified in the first inter-AS network map toremote PIDs of the first inter-AS network map that include prefixes ofthe “split” master network map PIDs from the PIDs of the AS.

As another example, two or more remote PIDs of a first inter-AS networkmap may together encompass two or more prefixes that are aggregated at aneighboring, originating one of ASes 40 into a single local PID of asecond inter-AS network map for the neighboring, originating AS. Asdescribed in further detail below with respect to FIG. 5, this may occurwhere, for example, the ALTO server 38 that generates the first inter-ASnetwork map receives routing information that specifies different pathsfrom local PIDs of the first inter-AS network map to the prefixes of theneighboring AS due to multiple ASBRs connecting the AS of the firstinter-AS network map to the neighboring AS.

In this instance, master ALTO server 38B reallocates the prefixes of thesingle local PID of the second inter-AS network map into two or moremaster network map PIDs that each encompasses a different set of theprefixes, grouped according to reachability from the AS of the firstinter-AS network map by respective ones of the different paths. In thisway, master ALTO server 38B aggregates all prefixes from remote PIDs ofthe first inter-AS network map that have a same cost from the AS of thefirst inter-AS network map into the same PID for the master network map.Because the various prefixes are aggregated into a single PID in thesecond inter-AS network map, the ALTO cost between these prefixes iszero. Master ALTO server 38B therefore sets the ALTO cost between thevarious pairs of the two or more master network map PIDs generated inthis manner to zero. Master ALTO server 38B sets the ALTO cost to thetwo or more “split” master network map PIDs from the PIDs of the AS ofthe first inter-AS network map according to the cost specified in thefirst inter-AS network map to remote PIDs of the first inter-AS networkmap that include prefixes of the “split” master network map PIDs fromthe PIDs of the AS.

As another example, a remote PID of a first inter-AS network map mayencompass a prefix that encompasses sub-prefixes (e.g., subnets) thatare aggregated at a neighboring, originating one of ASes 40 intomultiple local PIDs of a second inter-AS network map for theneighboring, originating AS. This circumstance may occur due to prefixaggregation, for instance. In this example, the multiple local PIDs ofthe second inter-AS network map control PID allocation within the masternetwork map.

FIG. 5 is a block diagram illustrating an example network 79 comprisingALTO servers 81A-81B (“ALTO servers 81”) that perform federated ALTOtechniques described herein. Network 79 includes autonomous systems80A-80B (“ASes 80”) that each includes a respective one of ALTO servers81. Autonomous systems 80 are interconnected via respective externalcommunication links (not shown) that connect pairs of autonomous systemboundary routers of ASes 80. For example, a first external communicationlink communicatively couples “ASBR2” (encompasses by PID 84B) of AS 80Aand “ASBR4” (encompassed by PID 84D) of AS 80B. Each of ASes 80 mayrepresent an example embodiment of one of autonomous systems 4 ofFIG. 1. Each of ALTO servers 81 may represent an example embodiment ofALTO server 12 of FIG. 1. Each of ASes 80 may be under administrativecontrol of one or more administrators or service providers. Whileillustrated as and described as ASBRs, any of the ASBRs may comprisearea boundary routers or any external BGP speaker.

Each of ALTO servers 81 performs dynamic network map generation andmodification techniques described in this disclosure to aggregateprefixes advertised by routers of associated ASes 80 into one or more ofPIDs 82 or PIDs 84 and assemble the PIDs into a respective inter-ASnetwork map for the AS that includes the ALTO server. As illustrated,for example, ALTO server 81A aggregates prefix P1 advertised by aninternal router of AS 80A into PID 82A. The internal router of AS 80Amay be set as a next hop attribute of PID 82A. ALTO server 81Aadditionally creates respective PIDs 84A, 84B for prefixes (in thiscase, network addresses) of each of the ASBRs of AS 80A. ALTO server 81Baggregates prefixes P2, P3 advertised by an internal router of AS 80Binto PID 82B. The internal router of AS 80B may be set as a next hopattribute of PID 82B. ALTO server 81B additionally creates respectivePIDs 84C, 84D for prefixes (in this case, network addresses) of each ofthe ASBRs of AS 80B. V

The various PIDs 82, 84 of each respective one of ASes 80 are connectedby intra-AS communication links. Each of ALTO servers 81 additionallyperforms dynamic cost map generation and modification techniquesdescribed herein to produce an inter-AS cost map that includes costs forvarious combinations of local and remote PIDs associated with thenetwork maps produced by the ALTO server. As a result, each of ALTOservers 81 produces local network and local cost maps that represent atopology of network 79 from the perspective of the associated one ofautonomous systems 80 for the ALTO server.

ALTO servers 81 federate with one another in an ALTO federation to shareinformation to foster fine PID prefix granularity throughout network 79and thereby improve node selection. ALTO server 81A is a master ALTOserver that, in addition to its local functions (i.e., generatingnetwork and cost maps from the perspective of AS 80A), generates masternetwork and cost maps for network 79 using the various local intra-ASand/or inter-AS network and cost maps generated by each of ALTO servers81.

ALTO server 81A receives routing information that advertises prefixesP2, P3 of AS 80B via a chain of topology information advertisements byrouters of ASes 80. In one example, the internal router of AS 80B sendsan IBGP UPDATE messages 86A, 86B that each includes prefixes P2, P3 tothe ASBRs of the AS 80B. The ASBRs of AS 80B reissues the messages asrespective BGP UPDATE message 88A, 88B to the ASBRs of AS 80A. TheASBRs, in turn, reissue the BGP UPDATES message 80A, 88B as IBGP UPDATEmessages 90A-90D. ALTO server 81A receives IBGP UPDATE message 90C fromthe ASBR encompassed by PID 84A, which is a next hop for a first routefor prefixes P2, P3. ALTO server 81A receives IBGP UPDATE message 90Dfrom the ASBR encompassed by PID 84B, which is a next hop for a secondroute for prefixes P2, P3. ALTO server 81A also receives routinginformation for prefix P1 of AS 80A.

ALTO server 81A also receives routing information that specifies linkmetrics for internal links of AS 80A and uses these metrics to computeALTO costs from PID 82A to PID 84A and from PID 82A to PID 84B. Inaddition, ALTO server 81A is configured with inter-AS costs for eachconnected pair of ASBRs of the ASes 80, which the ALTO server uses tocompute ALTO costs from PID 84A to PID 84C and from PID 84B to PID 84D.These ALTO costs are illustrated in FIG. 5 as unidirectional arrows withannotated cost information.

ALTO server 81B receives routing information for prefixes P2, P3 as wellas routing information that specifies link metrics for internal links ofAS 80A. ALTO server 81B uses the metrics to compute ALTO costs from PID84C to PID 82B and from PID 84D to PID 82B. In accordance with thetechniques of this disclosure, ALTO server 81B then uses the receivedrouting information to generate inter-AS network and cost maps for AS80B. ALTO server 81B sends the generated inter-AS network and cost mapsfor AS 80B to ALTO server 81A in upload message 92.

Because multiple network paths from PID 82A to PID 82B exist, ALTOserver 81A determines the network path along which the routers of AS 80Awill forward traffic to determine an accurate ALTO cost between thePIDs. Using the routing information received from the routers of AS 80A,ALTO server 81A selects one of the routes to prefixes P2, P3 accordingto a decision process, such as the BGP decision process described inRekhter et al., referenced above. So long as the policy configuration ofALTO server 81A and the internal router of AS 80A are similar regardingthe decision process, the decision process accurately determines thepath for traffic from PID 82A toward PID 82B. In some embodiments,rather than perform a decision process, ALTO server 81A accesses theLocal Routing Information Base (Loc-RIB) of the internal router of AS80A that is the next hop for PID 82A. The Loc-RIB specifies the routeselected by the internal router. In the illustrated embodiment, the pathfor traffic runs to PID 84A because of the lower internal routing costfrom the internal router of PID 82A to the ASBR of PID 84A.

Having determined the path for traffic from PID 82A to PID 82B, ALTOserver 81A sums the various ALTO costs for the path links, which includethe link from PID 82A to PID 84A, from PID 84A to PID 84C, and from PID84C to PID 82B. The ALTO cost for the link from PID 82A to PID 84A isspecified by the inter-AS network map generated by ALTO server 81A forAS 80A, as is the ALTO cost for the link from PID 84A to PID 84C. TheALTO cost for the link from PID 84C to PID 82B is specified by theinter-AS network map generated by ALTO server 81B and sent to ALTOserver 81A in upload message 92. In this instance, the sum of thevarious ALTO costs equals 190.

FIG. 6A is a block diagram illustrating an example graph 94 thatrepresents a partial combined intra-AS network and cost map for AS 80Bof FIG. 5 that is generated by ALTO server 81B, according to thedescribed techniques. Graph 94 is partial in that it does not includeALTO costs in both directions. In some embodiments, graph 94 is acombined inter-AS network and cost map that incorporates elements of AS80A. ALTO server 81B sends the network and cost maps represented bygraph 94 to ALTO server 81A.

FIG. 6B is a block diagram illustrating an example graph 96 thatrepresents a partial combined master network and cost map for network 79of FIG. 5. Graph 96 is partial in that it does not include ALTO costs inboth directions. ALTO server 81A generates the master network and costsmaps for network 79 using received routing information, configuredinter-AS costs, and a network and cost map received from ALTO server 81Bfor AS 80B.

FIG. 7 is a block diagram illustrating, in detail, an example ALTOserver 100 that receives routing information and dynamically generatesnetwork and cost maps in accordance with the techniques describedherein. ALTO server 100 may represent an example embodiment of any ofALTO servers 12 of FIG. 1, ALTO servers 38 of FIG. 3, or ALTO servers 81of FIG. 5. ALTO server 100 may be a server, network controller, networkswitch, or other computing device or appliance that includes one or moremicroprocessors that provide an operating environment for one or moresoftware modules for dynamically generating and outputting ALTO networkand cost maps in accordance with the described techniques. For purposeof clarity, components, such as a microprocessor, memory, keyboard,display, an operating system, network drivers and other componentscommonly found in such a computing device or appliance are not shown inFIG. 7. In some embodiments, ALTO server 100 comprises a router thatincludes one or more services units to apply services such as ALTOservices as described herein. The services units may be distributed overone or more service cards or blades (not shown) that are inserted intorack slots of a router. The services units may communicate with therouting plane across a backplane or across a network link that enablesthe ALTO services to passively peer with routing daemons executingrouting protocols within the routing plane of the router comprised byALTO server 100.

Control unit 102 of ALTO server 100 provides an operating environmentfor executing network map module 106, cost map module 112, clientinterface 114, IGP listener 130, BGP listener 124, and user interface128. Control unit 102 may comprise one or more processors (not shown),including one or more microprocessors, digital signal processors (DSPs),application specific integrated circuits (ASICs), field programmablegate arrays (FPGAs), or any other equivalent integrated or discretelogic circuitry, as well as any combinations of such components, toexecute modules that implement the functionality described herein.

Map modules 104 of ALTO server 100 dynamically generate network map 120and cost map 122 using routing information received with IGP listener130 and reachability information, e.g., in the form of topologyinformation advertisements, received with BGP listener 124. In someinstances, map modules 104 dynamically generate network map 120 and costmap 122 using routing information and reachability information receivedwith BGP listener 124 in BGP advertisements that include trafficengineering data. In addition, in the illustrated embodiment, ALTOserver 100 comprises topology information base 116, a data structurethat includes information regarding network topology, transmission costsfor various network links, and other information that may be used by mapmodules 104 to generate ALTO-based maps (i.e., network map 120 and costmap 122). Topology information base 116 may comprise one or more routinginformation bases (RIBs). Topology information base 116 may furthercomprise a traffic engineering database. Network map module 106 of mapmodules 104 uses topology information base 116 and community attributemap 118 (illustrated as “community attr. map 118”) to generate networkmap 120 according to the techniques described herein. Cost map module112 of map modules 104 may use dynamically generated network map 120 andtopology information base 116 to generate cost map 122 according to thetechniques described herein. In some instances, network map module 106additionally generates a master network map for a network using two ormore inter-AS network maps, and cost map module 112 generates a mastercost map for a network using two or more inter-AS cost maps.

Network map 120 may comprise an intra-AS and/or inter-AS network mapdynamically generated in accordance with the described techniques.Network map 120 includes one or more PID entries that comprise a datastructure to store a corresponding one or more PIDs of the network map.Each PID entry may include one or more aggregated prefixes, and PIDidentifier or name, and any attributes for the PID. Cost map 122 maycomprise an intra-AS and/or inter-AS cost map dynamically generatedaccording to the described techniques. Cost map 122 may comprise, forexample, one or more cost map entries that each specifies two PIDs ofnetwork map 120 and an ALTO cost for the two PIDs.

User interface 128 of ALTO server 100 may comprise a command-lineinterface (CLI), a graphical user interface (GUI), a remote procedurecall (RPC), or some other method to enable administrator 138 toconfigure topology information base 116 and provisioning policies 126 ofALTO server 100. Administrator 138 may be a network operator of, e.g., aservice provider network, or a software agent executing, e.g., on anetwork management device. Administrator 138 provisions ALTO server 100with provisioning policies 126, a set of policies that cause network mapmodule 106 to generate network map 120 and cost map module 112 togenerate cost map 122 in accordance with administrator preferencesrelating to transmission costs, load balancing, service-discrimination,PID grouping, community attribute to PID identifier mappings, or otherpreference areas. For example, a policy in provisioning policies 126 maydirect cost map module 112 to compute ALTO costs from IGP metrics,stored in topology information base 116, according to a particularformula. As another example, a policy in provisioning policies 126 maydirect network map module 106 to aggregate prefixes tagged with aparticular community attribute into a particular PID.

BGP listener 124 is a reachability protocol listener that executes BGPto peer with BGP speakers to receive BGP UPDATE messages 134 thatinclude NLRI for installation to topology information base 116. BGPlistener 124 may store a Loc-RIB (Local Routing Information Base) and/oran Adj-RIB-In (Adjacent Routing Information Base, Incoming) for each BGPpeer of ALTO server 100 (not shown). In addition, administrator 138 mayadd, modify, or remove routing information from topology informationbase 116 using UI 128. In some instances, BGP listener 124 receivestraffic engineering data encoded within BGP advertisements received fromthe BGP speakers. BGP listener 124 stores the traffic engineering datato a traffic engineering database (TED) of topology information base116, which map modules 104 use to dynamically generate network map 120and cost map 122.

IGP listener 130 is a routing protocol listener that executes aninterior gateway protocol to receive routing information 136 fromnetwork routers for installation to topology information base 116. Insome embodiments, IGP listener 130 executes OSPF to peer withneighboring routers to receive the LSDB and link-state updates for theautonomous system that includes ALTO server 100. In such embodiments,topology information base 116 comprises the LSDB.

Community attribute map 118 (illustrated as “community attr. map 118”)is an associative data structure, such as a table, list, or map, thatmaps community attribute values to corresponding PID attribute values.Community attributes and PID attributes may be derived from differentnamespaces. For example, a community attribute is typically a four byteinteger, while a PID attribute may be a string. Community attribute map118 operates as a lookup data structure that is keyed to communityattribute values. That is, for a community attribute value (e.g., avalue that specifies endpoints of type “CDN node”), community attributemap 118 provides a corresponding PID attribute value (e.g., a value thatidentifies PIDs associated with endpoints of type “CDN node”).

PID generator 110 aggregates endpoints described in topology informationbase 116 into PIDs and performs other PID generation, modification, and“splitting” techniques described in this disclosure. PID generator 110dynamically aggregates destination prefix received in BGP UPDATEmessages 134 into a new PID of network map 120 or modifies an existingPID of network map 120 to incorporate the destination prefix. Whenindividual ones of BGP UPDATE messages 134 include community attributes,attribute module 108 assigns the PID attribute value, mapped by BGPlistener 124 using the community attribute value received in BGP UPDATEmessage 134, to the new or modified PID that includes the destinationprefix.

Network map module 106 assembles the aggregated PIDs generated by PIDgenerator 110 into network map 120 according to the techniques describedherein. Cost map module 112 applies provisioning policies 126 to networkmap 120 and, in some instances, topology information base 116 togenerate a corresponding cost map 122. PID attributes for PIDs ofnetwork map 120 dynamically determined from BGP UPDATE messages 134 mayaffect determination by cost map module 122 of inter-PID costs. Forexample, provisioning policies 126 may include a policy requiring costmap module 122 to set to infinity inter-PID costs for PID pairs havingPIDs that both include a PID attribute value of “host.” In this example,an application using the ALTO service provided by ALTO server 100 thatreceives a content request from a host endpoint will therefore notselect another host endpoint to serve the requested content. Theapplication, in the form of a request router for example, may insteadselect a CDN node.

Client interface 114 exposes an ALTO server interface to enable ALTOclients to request and receive network and cost maps for an applicationfor the network. Client interface 114 sends a copy of network map 120and cost map 122 to a requesting client in maps upload message 132. Anyupdate message 132 may comprise an incremental or a complete update, asdescribed in Raghunath et al. incorporated above.

Client interface 114 may execute one or more protocols to obtain networkaddresses of ALTO clients in the network, and the client interfacemaintains these network addresses so as to push incremental updates ofthe maps to the clients. Example interfaces for client interface 114 mayinclude Simple Object Access Protocol (SOAP) or other eXtensible MarkupLanguage (XML) interfaces, a CLI or GUI, Simple Network ManagementProtocol (SNMP), Remote Procedure Calls (RPCs), and a Common ObjectRequest Broker Architecture (CORBA) interface, for example.

In some embodiments of ALTO server 100, client interface 114 implementsan endpoint cost service. When client interface 114 receives, from aclient, a list of endpoints represented in network map 120, clientinterface 114 returns an ordinally ranked list of the endpoints or thecosts, specified by cost map 122, between the endpoints and the clientor between the endpoints and another specified source node.Alternatively, client interface 114 returns costs between each of theendpoints and the client or between each of the endpoint and anotherspecified source node.

In some instances, ALTO server 100 may operate as a master ALTO serverand generate master network and cost maps for a network. In theseinstances, client interface 114 operates to communicate between ALTOserver 100 and various other ALTO servers located within otherautonomous systems of the network. Client interface 114 receives networkand cost maps from these various other ALTO servers. Upon consolidationof these network and cost maps by map modules 104 into a master networkand cost map, client interface 114 sends the master network and costmaps to the various other ALTO servers to provide a high-resolutionnetwork topology and cost information to other areas of the network.

FIG. 8 is a flowchart illustrating an example mode of operation of ALTOserver 100 for dynamically generating or modifying an inter-AS networkmap for an autonomous system served by ALTO server 100 according to thedescribed techniques. BGP listener 124 operates as a passive BGPlistener to peer with BGP speakers of the autonomous system and receiveBGP messages (200). BGP in this instance may refer to Interior BGP. WhenBGP listener 124 receives a BGP UPDATE message, BGP listener 124installs the received route to topology information base 116 (202). Insome instances, ALTO server 100 runs a BGP decision process overtopology information base 116 to select routes for processing.

Network map module 106 of ALTO server 100 analyzes the BGP UPDATEmessage attributes to determine whether the route originated in theautonomous system (AS) of ALTO server 100, that is, if the length of theAS_PATH attribute is equal to zero (203). If the route originated in adifferent AS (NO branch of 203), PID generator 110 adds the advertisedprefix to a PID of network map 120 (in this example, an inter-AS networkmap) that has both the same AS_PATH attribute and the same NEXT_HOPattribute as that of the route (214). If such a PID does not yet existin network map 120, PID generator 110 creates a new PID, sets the PIDNEXT_HOP attribute to the NEXT_HOP value of the route, sets the PIDAS_PATH attribute to the AS_PATH value of the route, and adds the prefixto the new PID in network map 120. If some instances, network map module106 generates an intra-AS network map that only includes prefixes servedby the autonomous system of ALTO server 100. In such instances, PIDgenerator 110 ignores all advertised prefixes for which the AS_PATHlength exceeds 0 and may therefore skip step 214.

If the route originated in the AS of ALTO server 100 (YES branch of203), attribute module 108 determines whether the route includes a BGPcommunity attribute or extended community attribute that is mapped, inprovisioning policies 126, to a particular PID (204). If so (YES branchof 204), then attribute module 108 directs PID generator 110 to add theadvertised prefix to the mapped PID (206). If necessary, PID generator110 creates the mapped PID in network map 120.

Attribute module 108 determines whether any of the one or more communityattribute values embedded in the BGP UPDATE message are mapped withincommunity attribute map 118 to PID attribute values (208). If so (YESbranch of 208), attribute module 108 directs PID generator 110 to addthe advertised prefix to a PID in network map 120 that (1) has the sameset of mapped PID attributes to which the community attribute values ofthe prefix are mapped in community attribute map 118, and (2) also hasthe same NEXT_HOP attribute as the advertised prefix (210). In otherwords, PID generator 110 aggregates prefixes tagged with the same set ofmapped community attribute values and the same NEXT_HOP into a singlePID. If necessary, PID generator 110 creates such a PID in network map120.

If the advertised prefix is not mapped in either community attribute map118 or provisioning policies 126, PID generator 110 adds the prefix to aPID in network map 120 that has no mapped PID attribute value and theyet has the same NEXT_HOP attribute as the advertised prefix (212). Ifnecessary, PID generator 110 creates such a PID in network map 120.After dynamically generating or modifying network map 120, clientinterface 114 provides the updated network map to ALTO clients of ALTOserver 100 in update message 132 (216).

FIGS. 9A-9D present a flowchart that illustrates an example operation ofALTO server 100 to dynamically generate or modify an inter-AS cost mapfor an autonomous system served by ALTO server 100 according to thetechniques described herein. IGP listener 130 executes a routingprotocol to receive routing information in routing protocol messagesfrom internal routers of the autonomous system that includes ALTO server100 (230). When IGP listener 130 receives routing protocol information(232), such as link-state advertisements, IPG listener 130 installs therouting information to a link-state database of topology informationbase 116 (234). In accordance with the routing protocol, IGP listener130 executes a shortest-path first algorithm over the LSDB to computeIGP metric between routers of the autonomous system that includes ALTOserver 100 (236). IGP listener 130 may store the IGP metrics to topologyinformation base 116.

Cost map module 112 of ALTO server 100 computes and sets ALTO costs foreach PID pair generated by network map module 106 in cost map 122. Inthis instance, the cost map is an inter-AS cost map. In some instances,however, cost map module 112 generates an intra-AS in addition to, orinstead of, the inter-AS cost map as cost map 122.

Cost map module 112 computes ALTO costs differently for differentcombinations of PID pair member PID types. For each PID pair in networkmap 120 (238), cost map module 112 determines whether both member PIDsof the PID pair include prefixes that are local to the autonomous systemthat includes ALTO server 100 (i.e., whether the member PIDs are localPIDs) (240). If so (YES branch of 240), cost map module 112 determinesthe IGP metric, from topology information base 116, between therespective next hop routers identified in the NEXT_HOP attribute of themember PIDs of the PID pair (250). Cost map module 112 applies one ormore policies of provisioning policies 126 to the determined IGP metricto compute an ALTO cost for the PID pair (252), then sets this ALTO costfor the PID pair in cost map 122 (254).

If one member PID of the PID pair is local and the other member PID isnon-local (i.e., remote) (NO branch of 240), then cost map 112determines whether the remote member PID is located in a neighboringautonomous system, as identified for example by the remote member PID ASidentifier attribute (242). If located in a neighboring AS (YES branchof 242), client interface 114 receives a partial cost map from an ALTOserver of the neighboring autonomous system that serves the prefixes ofthe remote PID (260). The partial cost map includes ALTO Network mapmodule 106 runs a BGP decision process with topology information oftopology information base 116 that accords with the perspective of thelocal PID member of the PID pair in order to identify the likely trafficpath from the local PID to the remote PID (262).

The ALTO cost for the PID pair is the sum of the intra-AS and inter-ASALTO costs for the identified traffic path. Cost map module 112 queriestopology information base 116 to obtain the IGP metric between the nexthop router identified in the NEXT_HOP attribute of the local member PIDand the next hop router identified in the NEXT_HOP attribute of theremote member PID (264). Cost map module 112 applies one or morepolicies of provisioning policies 126 to the determined IGP metric tocompute an intra-AS ALTO cost (266). Cost map module 112 an inter-ASALTO cost between the border routers that connect the AS and theneighboring AS along the identified traffic path (268). This inter-ASALTO may be configured in topology information base 116. Cost map module112 queries the partial cost map received by client interface 114 toobtain a remote ALTO cost between the border router of the neighboringAS that lies along the identified traffic path and prefixes of theremote PID (270). Cost map module 112 computes the sum of the intra-AScost, the remote cost, and the inter-AS cost (272) and sets the sum asthe ALTO cost for the PID pair in cost map 122 (274).

If the PID pair includes both a local PID and a non-neighbor remote PID(YES branch of 244), the ALTO cost for the PID pair is set as the sum ofthe intra-AS cost and the inter-AS cost from the autonomous system thatincludes ALTO server 100 to the remote AS that serves the prefixes ofthe remote PID. Cost map module 112 queries topology information base116 to obtain the IGP metric between the next hop router identified inthe NEXT_HOP attribute of the local member PID and the next hop routeridentified in the NEXT_HOP attribute of the remote member PID (280).Cost map module 112 applies one or more policies of provisioningpolicies 126 to the determined IGP metric to compute an intra-AS ALTOcost (282).

In this example, a default inter-AS ALTO cost is configured in topologyinformation base 116. Cost map module 112 next determines the AS_PATHlength from the AS_PATH attribute of the remote PID and then computesthe inter-AS ALTO cost as the product of the AS_PATH length and thedefault inter-AS ALTO cost (284). Cost map module 112 sums the inter-ASALTO cost with the intra-AS ALTO cost (286) and sets the sum as the ALTOcost for the PID pair in cost map 122 (288). In some instances,administrator 138 configures topology information base 116 with inter-AScosts between autonomous system identified by AS ID. In such instances,cost map module 116 may query topology information base 116 to obtain amore accurate inter-AS costs to compute a total inter-AS cost from thelocal PID to the remote PID.

If both members of the PID pair are remote PIDs (NO branch of 244), thecost map module 112 sets the ALTO cost for the PID pair as proportionalto the number of inter-AS links between the remote PIDs (246). In oneexample, cost map module 112 may determine the number of inter-AS linksby analyzing the AS_PATH attributes of the remote PIDs to find theAS_PATH value that includes each of the respective AS IDs of therespective ASes that serve the remote PIDs. Cost map module 112determines the number of inter-AS links from the determined value andcalculates the ALTO cost as the product of the number of inter-AS linksand the default inter-AS ALTO cost. If neither PID has such an AS_PATHvalue, cost map module 112 may be unable to determine the inter-AS ALTOcost and sets the ALTO cost for the PID pair to infinity. Afterdynamically generating or modifying cost map 122, client interface 114provides the updated cost to ALTO clients of ALTO server 100 in updatemessage 132 (248).

FIG. 10 is a flowchart illustrating an example operation of ALTO server100 to generate a master ALTO network map according to the techniquesset forth herein. In this example operation, client interface 114receives first and second inter-AS network maps from respective ALTOservers operating within first and second autonomous systems (300). Insome examples, ALTO server 100 may comprise one of these respective ALTOservers and in such examples ALTO server 100 uses inter-AS network andcost map that it has generated to generate master network and cost maps.

The inter-AS network maps each include local PIDs that network mapmodule 106 “carries over” to network map 120 (in this operation, networkmap 120 is a master network map for the network) (302). That is, networkmap module 106 copies the prefixes, attributes, and other values of thelocal PIDs into corresponding PIDs for network map 120.

For each of the first and second inter-AS network maps (304), networkmap module 106 compares the remote PIDs of the inter-AS network map tolocal PIDs carried over to the master network map 120 from the otherinter-AS network map (306). In particular, network map module 106 splitsPIDs of the master network map 120 when such PIDs, corresponding tolocal PIDs of the other inter-AS network map, have prefixes that are notadvertised to the AS of the inter-AS network map, as evidenced byprefixes that are not included in the remote PIDs (308).

In addition, network map module 106 splits PIDs of the master networkmap 120 when such PIDs, corresponding to local PIDs of the otherinter-AS network map, have divergent AS_PATH lengths according to theremote PIDs (310). That is, when the remote PIDs separate prefixes to asingle local PID of the other inter-AS network map according todifferent AS_PATH lengths to the prefixes, network map module 106 splitsthe corresponding PID for the local PID in master network map 120according to the separation defined by the remote PIDs. Network mapmodule 106 additionally splits PIDs of the master network map 120 whensuch PIDs, corresponding to local PIDs of the other inter-AS networkmap, have divergent NEXT_HOP attribute values according to the remotePIDs (312). That is, when the remote PIDs separate prefixes to a singlelocal PID of the other inter-AS network map according to differentNEXT_HOP values for the prefixes, network map module 106 splits thecorresponding PID for the local PID in master network map 120 accordingto the separation defined by the remote PIDs. After dynamicallygenerating or modifying master network map 120, client interface 114provides the updated network map in update message 132 to ALTO clientsof ALTO server 100 or to other ALTO servers in various ASes of thenetwork (314).

FIG. 11 is a flowchart illustrating an example operation of ALTO server100 to generate master ALTO network and cost maps according to thetechniques set forth herein. In this example operation, client interface114 receives first and second inter-AS network and cost maps fromrespective ALTO servers operating within first and second autonomoussystems (326). In some examples, ALTO server 100 may comprise one ofthese respective ALTO servers and in such examples ALTO server 100 usesinter-AS network and cost map that it has generated to generate masternetwork and cost maps. Network map module 106 generates a master networkmap 120 using the first and second inter-AS network maps (328). Whileillustrated and described sequentially, the operations of generating amaster network map 120 and master cost map 122 may occur concurrently.

Cost map module 112 then assembles corresponding master cost map 122 formaster network map 120. In this example, for each PID pair in masternetwork map 120 (330), cost map module 112 determines whether bothmember PIDs are carried over from the same inter-AS network map, i.e.,whether the PIDs are served by the same autonomous system (332). If so(YES branch of 332), cost map module 112 sets the ALTO cost for the PIDpair to the ALTO cost for the corresponding PIDs as specified in theinter-AS cost map for the autonomous system that serves the PIDs (334).If the PID members represent a “split” PID that network map module 106created to account for divergence in the first and second inter-ASnetwork maps, cost map module 112 sets the ALTO cost for the PID pair tozero to reflect that the prefixes of these PID are aggregated into thesame PID by the ALTO server of the autonomous system that serves thesePIDs (338).

If the PID members include prefixes from both the first and secondinter-AS network maps (NO branch of 336), cost map module 112 sets theunidirectional ALTO costs between the PID members using costs from boththe first and second inter-AS cost maps. Specifically, cost map module112 sets the ALTO cost from the first PID member to the second PIDmember in master cost map 122 as the cost specified by the inter-AS costmap provided by the autonomous system that serves the first PID (340).Cost map module 112 sets the ALTO cost from the second PID member to thefirst PID member in master cost map 122 as the cost specified by theinter-AS cost map provided by the autonomous system that serves thesecond PID (342). After generating the master network and cost maps,client interface 114 provides the updated maps in update message 132 toALTO clients of ALTO server 100 or to other ALTO servers in various ASesof the network (344).

The techniques described in this disclosure may be implemented, at leastin part, in hardware, software, firmware or any combination thereof. Forexample, various aspects of the described techniques may be implementedwithin one or more processors, including one or more microprocessors,digital signal processors (DSPs), application specific integratedcircuits (ASICs), field programmable gate arrays (FPGAs), or any otherequivalent integrated or discrete logic circuitry, as well as anycombinations of such components. The term “processor” or “processingcircuitry” may generally refer to any of the foregoing logic circuitry,alone or in combination with other logic circuitry, or any otherequivalent circuitry. A control unit comprising hardware may alsoperform one or more of the techniques of this disclosure.

Such hardware, software, and firmware may be implemented within the samedevice or within separate devices to support the various operations andfunctions described in this disclosure. In addition, any of thedescribed units, modules or components may be implemented together orseparately as discrete but interoperable logic devices. Depiction ofdifferent features as modules or units is intended to highlightdifferent functional aspects and does not necessarily imply that suchmodules or units must be realized by separate hardware or softwarecomponents. Rather, functionality associated with one or more modules orunits may be performed by separate hardware or software components, orintegrated within common or separate hardware or software components.

The techniques described in this disclosure may also be embodied orencoded in a computer-readable medium, such as a non-transitorycomputer-readable medium or computer-readable storage medium, containinginstructions. Instructions embedded or encoded in a computer-readablemedium may cause a programmable processor, or other processor, toperform the method, e.g., when the instructions are executed. Computerreadable storage media may include random access memory (RAM), read onlymemory (ROM), programmable read only memory (PROM), erasableprogrammable read only memory (EPROM), electronically erasableprogrammable read only memory (EEPROM), flash memory, a hard disk, aCD-ROM, a floppy disk, a cassette, magnetic media, optical media, orother computer-readable storage media. It should be understood that theterm “computer-readable storage media” refers to physical storage media,and not signals or carrier waves, although the term “computer-readablemedia” may include transient media such as signals, in addition tophysical storage media.

Various embodiments of the invention have been described. These andother embodiments are within the scope of the following claims.

1-20: (canceled) 21: A method comprising: storing, by anapplication-layer traffic optimization (ALTO) server, layer 3 topologyinformation that specifies one or more endpoints, a next hop attributethat indicates a next hop for the one or more endpoints, an autonomoussystem path attribute that indicates an autonomous system path for theone or more endpoints, and a communities path attribute that indicatesthe one or more endpoints share a common property; generating, by theALTO server based at least on the community value for the one or moreendpoints, a provider-defined identifier (PID) that includes the one ormore endpoints; and providing, by the ALTO server, an ALTO service to aclient device in accordance with an ALTO network map that includes thePID. 22: The method of claim 21, further comprising: receiving, by theALTO server, a layer 3 topology information advertisement that includesthe layer 3 topology information. 23: The method of claim 21, furthercomprising: receiving, by the ALTO server, a Border Gateway Protocol(BGP) UPDATE message that includes the layer 3 topology information,wherein Network Layer Reachability Information of the BGP UPDATE messagespecifies the one or more endpoints, wherein a NEXT_HOP path attributeof the BGP UPDATE message indicates the next hop for the one or moreendpoints, wherein an AS_PATH path attribute of the BGP UPDATE messageindicates the autonomous system path for the one or more endpoints, andwherein a BGP COMMUNITIES path attribute indicates the community valuefor the one or more endpoints. 24: The method of claim 21, wherein thecommunities path attribute comprises one of a Border Gateway Protocol(BGP) COMMUNITIES path attribute, a BGP EXTENDED COMMUNITY pathattribute, and a combination of a BGP COMMUNITIES path attribute and aBGP EXTENDED COMMUNITY path attribute. 25: The method of claim 21,further comprising: applying, by the ALTO server, a community attributemap to the attribute value to map the attribute value for the one ormore endpoints to a PID identifier that identifies the PID, whereingenerating the PID comprises generating, by the ALTO server, the PIDbased at least on the PID identifier. 26: The method of claim 21,wherein the client device comprises one of a peer-to-peer device, acontent request router, and another ALTO server. 27: The method of claim21, wherein providing the ALTO service comprises one of sending the ALTOnetwork map to the client device and selecting, based at least on theALTO network map, one of the one or more endpoints of the PID for acontent request received by the ALTO server. 28: The method of claim 21,wherein the common property shared by the one or more endpoints affectsan application layer cost for application layer traffic exchangedbetween the one or more endpoints of the PID and one or more endpointsof at least one other PID of the ALTO network map. 29: The method ofclaim 21, further comprising: computing, by the ALTO server based atleast on the attribute value, an application layer cost between the PIDand at least one other PID of a plurality of PIDs of the ALTO networkmap, wherein providing the ALTO service comprises providing the ALTOservice based at least on the application layer cost between the PID andthe at least one other PID. 30: An application-layer trafficoptimization (ALTO) server comprising: at least one processor operablycoupled to a memory; a database for a routing protocol, the databaseconfigured to store layer 3 topology information that specifies one ormore endpoints, a next hop attribute that indicates a next hop for theone or more endpoints, an autonomous system path attribute thatindicates an autonomous system path for the one or more endpoints, and acommunities path attribute that indicates the one or more endpointsshare a common property; a network map module configured for executionby the at least one processor to generate, based at least on thecommunity value for the one or more endpoints, a provider-definedidentifier (PID) that includes the one or more endpoints; a clientinterface configured for execution by the at least one processor toprovide an ALTO service to a client device in accordance with an ALTOnetwork map that includes the PID. 31: The ALTO server of claim 30,further comprising: a protocol listener configured for execution by theat least one processor to receive a layer 3 topology informationadvertisement that includes the layer 3 topology information. 32: TheALTO server of claim 30, further comprising: a protocol listenerconfigured for execution by the at least one processor to receive aBorder Gateway Protocol (BGP) UPDATE message that includes the layer 3topology information, wherein Network Layer Reachability Information ofthe BGP UPDATE message specifies the one or more endpoints, wherein aNEXT_HOP path attribute of the BGP UPDATE message indicates the next hopfor the one or more endpoints, wherein an AS_PATH path attribute of theBGP UPDATE message indicates the autonomous system path for the one ormore endpoints, and wherein a BGP COMMUNITIES path attribute indicatesthe community value for the one or more endpoints. 33: The ALTO serverof claim 30, wherein the communities path attribute comprises one of aBorder Gateway Protocol (BGP) COMMUNITIES path attribute, a BGP EXTENDEDCOMMUNITY path attribute, and a combination of a BGP COMMUNITIES pathattribute and a BGP EXTENDED COMMUNITY path attribute. 34: The ALTOserver of claim 30, wherein the network map module is further configuredto apply a community attribute map to the attribute value to map theattribute value for the one or more endpoints to a PID identifier thatidentifies the PID, and wherein generating the PID comprises generating,by the ALTO server, the PID based at least on the PID identifier. 35:The ALTO server of claim 30, wherein the client device comprises one ofa peer-to-peer device, a content request router, and another ALTOserver. 36: The ALTO server of claim 30, wherein the client interface isfurther configured to provide the ALTO service by one of sending theALTO network map to the client device and selecting, based at least onthe ALTO network map, one of the one or more endpoints of the PID for acontent request received by the ALTO server. 37: The ALTO server ofclaim 30, wherein the common property shared by the one or moreendpoints affects an application layer cost for application layertraffic exchanged between the one or more endpoints of the PID and oneor more endpoints of at least one other PID of the ALTO network map. 38:The ALTO server of claim 30, further comprising: an ALTO cost map moduleconfigured for execution by the at least one processor to compute, basedat least on the attribute value, an application layer cost between thePID and at least one other PID of a plurality of PIDs of the ALTOnetwork map, wherein the client interface is further configured toprovide the ALTO service based at least on the application layer costbetween the PID and the at least one other PID. 39: A non-transitorycomputer-readable medium comprising instructions that, when executed,cause one or more processors of an application-layer trafficoptimization (ALTO) server to: store layer 3 topology information thatspecifies one or more endpoints, a next hop attribute that indicates anext hop for the one or more endpoints, an autonomous system pathattribute that indicates an autonomous system path for the one or moreendpoints, and a communities path attribute that indicates the one ormore endpoints share a common property; generate, based at least on thecommunity value for the one or more endpoints, a provider-definedidentifier (PID) that includes the one or more endpoints; and provide anALTO service to a client device in accordance with an ALTO network mapthat includes the PID.